idnits 2.17.1 draft-winterbottom-http-location-delivery-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2311. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 200 (Success): This code indicates that the request was successful. This code MUST not be used for an error response. -- 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 23, 2006) is 6393 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) == Missing Reference: '0-5' is mentioned on line 1317, but not defined == Missing Reference: '0-9' is mentioned on line 1317, but not defined ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3693 == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-04 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew 5 Expires: April 26, 2007 B. Stark 6 BellSouth 7 October 23, 2006 9 HTTP Enabled Location Delivery (HELD) 10 draft-winterbottom-http-location-delivery-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 26, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 A Geopriv using protocol is described that is used for retrieving 44 location information from a server within an access network. The 45 protocol includes options for retrieving location information either 46 by-value or by-reference. The protocol supports mobile and nomadic 47 devices through Location URIs. The protocol is an application-layer 48 protocol that is independent of session-layer; an HTTP, web services 49 binding is specified. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Device or Target . . . . . . . . . . . . . . . . . . . . . 5 56 1.3. The Bigger Picture . . . . . . . . . . . . . . . . . . . . 5 57 2. Conventions used in this document . . . . . . . . . . . . . . 7 58 2.1. GEOPRIV Terminology . . . . . . . . . . . . . . . . . . . 7 59 3. HELD Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Requesting Location Information Directly . . . . . . . . . 9 61 3.1.1. Shaping the PIDF-LO . . . . . . . . . . . . . . . . . 10 62 3.2. Requesting a Location URI . . . . . . . . . . . . . . . . 10 63 3.2.1. Establishing a Location Server Context . . . . . . . . 11 64 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 13 65 4.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 14 66 4.2. Location Request . . . . . . . . . . . . . . . . . . . . . 14 67 4.3. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.3.1. Creating Contexts . . . . . . . . . . . . . . . . . . 15 69 4.3.2. Updating Contexts . . . . . . . . . . . . . . . . . . 16 70 4.3.3. Terminating Contexts . . . . . . . . . . . . . . . . . 16 71 4.4. Combined Context and Location Requests . . . . . . . . . . 17 72 4.5. Indicating Errors . . . . . . . . . . . . . . . . . . . . 17 73 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 18 74 5.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 19 75 5.2. "assert" Parameter . . . . . . . . . . . . . . . . . . . . 19 76 5.2.1. "method" Parameter . . . . . . . . . . . . . . . . . . 19 77 5.2.2. "timestamp" Parameter . . . . . . . . . . . . . . . . 19 78 5.2.3. "expires" Parameter . . . . . . . . . . . . . . . . . 20 79 5.2.4. "exact" Parameter . . . . . . . . . . . . . . . . . . 20 80 5.3. "locationType" Parameter . . . . . . . . . . . . . . . . . 20 81 5.3.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 21 82 5.4. "profile" Parameter . . . . . . . . . . . . . . . . . . . 21 83 5.4.1. "presentity" Parameter . . . . . . . . . . . . . . . . 22 84 5.4.2. "retentionExpiry" Parameter . . . . . . . . . . . . . 22 85 5.4.3. "retentionInterval" Parameter . . . . . . . . . . . . 22 86 5.4.4. "retransmission" Parameter . . . . . . . . . . . . . . 23 87 5.4.5. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 23 89 5.5. "signed" Parameter . . . . . . . . . . . . . . . . . . . . 23 90 5.6. "lifetime" Parameter . . . . . . . . . . . . . . . . . . . 23 91 5.7. "rules" Parameter . . . . . . . . . . . . . . . . . . . . 23 92 5.7.1. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 24 93 5.7.2. Common Policy "ruleset" Parameter . . . . . . . . . . 24 94 5.8. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 24 95 5.9. "message" Parameter . . . . . . . . . . . . . . . . . . . 26 96 5.10. "context" Parameter . . . . . . . . . . . . . . . . . . . 26 97 5.10.1. "locationURI" Parameter . . . . . . . . . . . . . . . 26 98 5.10.2. "password" Parameter . . . . . . . . . . . . . . . . . 26 99 5.10.3. "expires" Parameter . . . . . . . . . . . . . . . . . 27 100 5.11. "location" Parameter . . . . . . . . . . . . . . . . . . . 27 101 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 7. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 7.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 34 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 105 8.1. Return Routability . . . . . . . . . . . . . . . . . . . . 37 106 8.2. Transaction Layer Security . . . . . . . . . . . . . . . . 38 107 8.3. Veracity of Asserted LI . . . . . . . . . . . . . . . . . 38 108 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 109 9.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 39 110 9.2. Location Request Examples . . . . . . . . . . . . . . . . 41 111 9.3. Context Creation and Update Examples . . . . . . . . . . . 43 112 9.4. Sample LG WSDL Document . . . . . . . . . . . . . . . . . 47 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 114 10.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 48 115 10.2. URN Sub-Namespace Registration for 116 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 48 117 10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 49 118 10.4. URN Sub-Namespace Registration for 119 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 49 120 10.5. MIME Media Type Registration for 'application/held+xml' . 50 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 122 11.1. Normative References . . . . . . . . . . . . . . . . . . . 52 123 11.2. Informative References . . . . . . . . . . . . . . . . . . 53 124 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 55 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 126 Intellectual Property and Copyright Statements . . . . . . . . . . 57 128 1. Introduction 130 The location of a Device is information that is useful for a number 131 of applications. A Device might be able to determine this 132 information using its own resources, but more often than not, the 133 Device must rely on its access network to provide this information. 134 This document describes a protocol that can be used to acquire 135 Location Information (LI) from a service within an access network. 137 This specification identifies two methods for acquiring LI. Location 138 may be retrieved from a Location Generator (LG) by-value, that is, 139 the Device may acquire LI directly. Alternatively, the Device may 140 request that the LG provide a location URI so that LI can be 141 distributed by-reference. Both of these methods are compatible, and 142 both can be provided concurrently from the same LG so that 143 application needs can be addressed individually. 145 This specification defines an XML-based protocol that enables the 146 retrieval of LI from a LG. This protocol can be bound to any 147 session-layer protocol, particularly those capable of MIME transport; 148 an HTTP binding is included as a minimum requirement. 150 1.1. Exclusions 152 This document defines a protocol for configuration purposes; that is, 153 a protocol for requesting (and receiving) the information necessary 154 to use LI. This document does not define a Geopriv Using Protocol. 155 The LG is assumed to be present within the same administrative domain 156 as the Device (the access network), which limits the security threats 157 that this protocol is exposed to. 159 This document does not specify how LI is derived. Determination of 160 the physical location of a network termination point is dependent on 161 the type of access network and the capabilities of networking 162 equipment. The specific methods that could be used are innumerable, 163 therefore this is left to individual network and equipment 164 implementations. 166 Providing LI by-reference implies that a server is able to provide 167 the Device with a public, globally-routable URI. How this URI is 168 provided is not covered by this specification. This includes any 169 interactions between the LG and LS necessary to facilitate the 170 provision of a Location URI. 172 This document does not define how an LG is discovered or configured. 173 Service discovery techniques are described in two separate documents, 174 [I-D.winterbottom-geopriv-held-dhcp-discovery] describing a DHCP 175 discovery mechansim, and [I-D.thomson-geopriv-held-unaptr] describing 176 a DNS lookup mechanism. 178 1.2. Device or Target 180 LI provided for the Device is often represented as the location of a 181 user. However, in this document LI is attributed to a Device and not 182 a person. Primarily, this is because location determination 183 technologies are generally designed to locate a Device and not a 184 person. In addition to this, unless the Device requires active user 185 authentication, there is no guarantee that any particular individual 186 is using the Device at that instant. Thus, if any claim of veracity 187 is to be made for LI, the distinction between Target and Device must 188 be made explicit. 190 This distinction should not lead to the impression that the location 191 of the Device does not impact the privacy constraints required by 192 this protocol. Revealing the location of the Device almost 193 invariably reveals some information about the location of the user of 194 the Device, therefore the same level of privacy protection demanded 195 by a user is required for the Device. 197 It is expected that, for most applications, this distinction will be 198 unnecessary: LI for the Device will be used as an adequate substitute 199 for the user's LI. This requires either some additional assurances 200 about the link between Device and Target, or an acceptance of the 201 aforementioned limitations. 203 This document assumes that the Device is responsible for the protocol 204 interactions described and that it does so with the authority of the 205 Target and Rule Maker (RM). 207 1.3. The Bigger Picture 209 This document describes an interface between a Device and a Location 210 Generator (LG). Detailing the interactions between these two 211 entities requires a wider understanding of other interested parties. 213 For the Device, the most important consideration is the Target. In 214 some cases, this is the same as the Device, but it is more likely to 215 be a human user. The foundation of this protocol is that the Target 216 is able to direct the dissemination of LI, that is, the Target 217 provides authorization policies and otherwise controls how LI is 218 granted to Location Recipients (LRs). This extends to when a 219 Location Server (LS) is employed to provide a Location URI; the LS 220 cannot provide LI to an LR without express permission from the 221 Target. 223 The LG exists as an access network service. An Access Provider (AP) 224 operates this service so that Devices (and Targets) can retrieve LI. 225 The LG exists because not all Devices are capable of determining LI, 226 and because, even if a Device is able to determine its own LI, it may 227 be more efficient with assistance. 229 The following diagram shows one possible configuration of the roles 230 identified in [RFC3693] and where this protocol applies. 232 +-----------+ +-----------+ 233 | Location | | Location | 234 | Generator | - - - - | Server | 235 | | | | 236 +-----------+ +-----------+ 237 | | 238 HELD | 239 | | 240 Rule Maker - _ +-----------+ +-----------+ 241 o - - | Device | | Location | 242 | (Target) |----Object--->| Recipient | 346 | | | (LS, RH) | | | 347 +-----------+ +----------+ +-----------+ 349 Figure 2: Simple Location Request Model 351 In this model, the Device in this scenario acts as a Location Server 352 (LS) and Rule Holder (RH); it is responsible for making authorization 353 decisions about which Location Recipients are given LOs. 355 The LG needs to uniquely identify the Device within the access 356 network. The source address of the request message is sufficient in 357 most cases. Once the Device is identified, the LG uses network 358 domain-specific information to determine the location of the Device. 360 An LI request does not need to include any identification information 361 other than return addressing. In fact, the HTTP binding (Section 7) 362 includes the option for a GET request. Return routability also 363 addresses a number of security concerns, see Section 8. 365 The response from the LG is a PIDF-LO document [RFC4119], unless 366 there were errors in processing the request. 368 The interface between Device (acting as LS) and Location Recipient 369 (LR) is application-specific and outside the scope of this 370 specification. 372 3.1.1. Shaping the PIDF-LO 374 A Device can include additional information in an LI request that 375 controls how the LG populates the fields in a PIDF-LO document. 376 Related to privacy, a presentity URI and usage rules can be 377 specified. The Device can also include a location estimate, or 378 request a specific type of location information, including a request 379 for a signed PIDF-LO. 381 When requesting LI, the Device can include a presentity URI for the 382 Target and a ruleset reference. The LG incorporates this information 383 in the PIDF-LO document, or modifies the document accordingly. 385 LI contained within a PIDF-LO document can be either geodetic 386 (coordinates using latitude and longitude or some other coordinate 387 system) or civic (street or postal addresses). The Device can 388 request that the LG provide a specific type of LI, including whether 389 a jurisdictional or postal civic address is required. 391 If a Device is capable of providing its own location it can include 392 this in a request. The LG is then able to include this LI in the 393 returned PIDF-LO. The type of LI is inferred from the request when 394 LI is provided. 396 The PIDF-LO document generated by an LG MUST follow the rules in 397 [I-D.ietf-geopriv-pdif-lo-profile]. The LI sent in a request MUST 398 follow the subset of those rules relating to the construction of the 399 "location-info" element. 401 3.2. Requesting a Location URI 403 Requesting LI directly does not always address the requirements of an 404 application. A Location URI is a URI [RFC3986] of any scheme, which 405 a Location Recipient (LR) can use to retrieve LI. A Device can 406 request a Location URI instead of LI. 408 Figure 3 illustrates how this usage of HELD fits within the model 409 presented in [RFC3693]. The first aspect of the diagram shows how 410 the Device acts as an agent for the Target and retrieves a Location 411 URI, which it then provides to the Location Recipient. The second 412 aspect has the Device acting as an agent for the Rule Maker; the 413 Device forwards rules to the LG, which forwards them to the LS. 415 +-----------+ Location +--------------+ 416 | Location |------URI------>| Device | 417 | Generator | | (Target) | 418 | |<-----Rules-----| (Rule Maker) | 419 +-----------+ +--------------+ 420 | | 421 LO & Rules Location URI 422 | | 423 V V 424 +----------+ +------------+ 425 | Location | Location | Location | 426 | Server |------Object----->| Recipient | 427 | | | | 428 +----------+ +------------+ 430 Figure 3: Location URI Usage Model 432 Note that the Location Server takes the role of a (Private) Rule 433 Holder when the rules are provided by-value. The rules may also be 434 provided to the LG and LS by-reference, in which case, a Public Rule 435 Holder is required; the Public Rule Holder is not shown in this 436 diagram. 438 The interface between Device (acting as LS) and Location Recipient 439 (LR) is application-specific and outside the scope of this 440 specification. Also, any interface between Device (acting as RM) and 441 a Public Rule Holder is not relevant to this specification. 443 The merits and drawbacks of using a Location URI approach are 444 discussed in [I-D.winterbottom-location-uri]. 446 3.2.1. Establishing a Location Server Context 448 A Location URI is allocated for a Device by the LS. If the LS is to 449 be able to service queries for location directed at the Location URI, 450 it must maintain certain information. When the LG receives a request 451 for a Location URI, it requests that the LS allocate a URI for a 452 particular Device. As a part of providing a Location URI, the LS 453 also creates a _context_, which contains the information that it 454 requires to properly service requests to the URI. 456 This document does not make any normative statements about the 457 interface between the LG and LS. Any assumptions that are made about 458 the nature of this interface are stated where necessary. 460 A context contains sufficient information for the LS to identify the 461 Device to the LG, so that LI can be generated as required, which 462 could be on a per-request basis. The context also includes 463 instructions from the Device on how the PIDF-LO is to be generated, 464 as described in Section 3.1.1. 466 The context contains an authorization policy that describes to whom, 467 and how, LI is granted. This is a common-policy document 468 [I-D.ietf-geopriv-common-policy] that is provided by the Device in 469 the context creation request, either directly, or by reference. 471 4. Protocol Description 473 As discussed in Section 3, this protocol provides two basic 474 functions: LI request and Location URI request. Messages are defined 475 as XML documents. 477 The Location Request message is described in Section 4.2. A Location 478 Request from a Device results in a PIDF-LO document in case of 479 success, or an error message. 481 In requesting a Location URI, the Device requests that a context be 482 created on the LS. The parameters for the create context request are 483 described in Section 4.3.1. The response to a context creation 484 request includes Location URIs and a password that can be used to 485 update the information contained in the context. The details stored 486 by the LS can be updated at any time after creation using the update 487 context request, described in Section 4.3.2. 489 Table 1 shows the basic set of messages supported by this protocol 490 and their respective responses, successful or otherwise. 492 +------------+------------------+-------------------+---------------+ 493 | Operation | Request Message | Successful | Error | 494 | | | Response | Response | 495 +------------+------------------+-------------------+---------------+ 496 | Request | locationRequest | PIDF-LO document | error | 497 | Location | (Section 4.2) | [RFC4119] | (Section 4.5) | 498 | | | | | 499 | Create | createContext | contextResponse | error | 500 | Context | (Section 4.3.1) | | (Section 4.5) | 501 | | | | | 502 | Update | updateContext | contextResponse | error | 503 | Context | (Section 4.3.2) | | (Section 4.5) | 504 +------------+------------------+-------------------+---------------+ 506 Table 1: HELD Operations 508 A MIME type "application/held+xml" is registered in Section 10.5 to 509 distinguish HELD messages from other XML document bodies. This 510 specification follows the recommendations and conventions described 511 in [RFC3023], including the naming convention of the type ('+xml' 512 suffix) and the usage of the 'charset' parameter. 514 Section 5 contains a more thorough description of the protocol 515 parameters, valid values, and how each should be handled. Section 6 516 contains a more specific definition of the structure of these 517 messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028]. 519 4.1. Protocol Binding 521 The HELD protocol is an application-layer protocol that is defined 522 independently of any lower layers. This means that any protocol can 523 be used to transport this protocol providing that it can provide a 524 few basic features: 526 o The protocol must have acknowledged delivery. 528 o The protocol must be able to correlate a response with a request. 530 o The protocol must provide authentication, privacy and protection 531 against modification. 533 Candidate protocols that could be used to address these purposes 534 include: TCP [RFC0793], TLS [RFC2246], SASL [RFC2222], HTTP 535 [RFC2616], SIP [RFC3261], BEEP [RFC3080] and SOAP 536 [W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part2-20030624]. 537 This document includes a binding that uses a combination of HTTP, TLS 538 and TCP in Section 7. 540 4.2. Location Request 542 A location request is sent from the Device to the LG when it requires 543 LI. This request can be very simple, including no parameters; in 544 fact, the HTTP binding includes a GET request that does not include a 545 message body. 547 A Device MAY make an assertion about its own location as part of a 548 location request. Devices that have some means of acquiring LI, 549 either from embedded technology like Global Positioning System (GPS) 550 receivers or from user input, can use this to convey that information 551 to the LG. The "assert" element can be used to convey this 552 information. 554 The type of LI that a Device requests is determined by the type of LI 555 that is included in the "assert" element. When asserted LI is not 556 provided, the Device MAY specify the type of location requested using 557 the "locationType" element. 559 LI provided by the Device is potentially more precise than that 560 provided by the LG, therefore the LG MAY use this information to 561 create a response. The LG SHOULD validate the LI provided for 562 accuracy and precision before using this information. 564 The Device MAY specify a "profile" element that instructs the LG on 565 how to construct the LO. Alternatively, if the Device has created a 566 profile in an LS context, the Device can provide a "context" element 567 so that the LG can retrieve the profile from the LS. 569 The location request is made by sending a document formed of a 570 "locationRequest" element. The successful response to a location 571 request is a PIDF-LO document, unless the request fails, in which 572 case the LG SHOULD provide an error indication document. 574 4.3. Contexts 576 A context is established by the LS in order to provide a Location 577 URI. The context includes information necessary to identify the 578 Device and determine its location when an LR requests an LO using the 579 Location URI. 581 4.3.1. Creating Contexts 583 The Device uses the "createContext" message to request that the LG, 584 and the LS, assign a Location URI. This establishes a context at the 585 LS. 587 The LS MUST maintain the information provided in the create context 588 request. The create context request includes a time limit, which 589 sets the maximum time that this context can be maintained. 591 The response to a create context request contains information that 592 the Device can use to identify a context. A set of Location URIs are 593 included, each one MUST uniquely identify the context; that is, the 594 LS MUST be able to identify a context based on a single Location URI. 595 A Device can distribute a Location URI to an LR to allow it retrieve 596 LI from the LS. 598 A Location URI MUST NOT contain any information that could be used to 599 identify the Device or Target. It is RECOMMENDED that a Location URI 600 contain a public address for the LS and a random sequence of 601 characters that the LS can use to identify a particular context. The 602 presentity identifier included in a PIDF-LO document SHOULD NOT be 603 used for either part or the entirety of a Location URI. 605 The response to a create context request MUST include the time when 606 the LS will terminate the context. The LS MUST NOT respond to any 607 queries to the context beyond this time. A response to a context 608 creation also includes a password that the Device uses to identify 609 itself when updating the context at any time before the context 610 expiry time. 612 4.3.2. Updating Contexts 614 A Device can update any of the information it has provided for a 615 context at any time. The update context request includes the same 616 information as the create context request with the addition of 617 information that identifies an existing context. 619 A Device uses any one of the Location URIs provided to uniquely 620 identify a context when updating context information. The context 621 password MUST be provided when updating context information. 623 If a Device includes an authorization policy (or ruleset) in an 624 update context request, the LS MUST refresh any stored copy of the 625 authorization policy. This is especially important for authorization 626 policies that are provided by-reference; the LS MUST update the 627 authorization policy, even if the URI has not changed. Updated 628 authorization policies MUST be processed by the LG and LS before any 629 subsequent requests from LRs are accepted; the LG and LS MAY defer 630 processing of the authorization policy until after a response is sent 631 to the Device. 633 The update context request is constructed using the "updateContext" 634 element. A successful response is the "contextResponse" element, 635 which is the same as the response to a create context response. 637 The update context request can also indicate that data can be removed 638 by the context by specifying a _nil_ value for any of the parameters, 639 using the "xsi:nil" attribute. This applies to the profile 640 (Section 5.4) element. 642 The response to an update context request is identical in form to the 643 create context response, with updated information about the context. 644 The Location URIs MUST be the same as those in the response to the 645 initial create context request, but the password and expiry time MAY 646 be changed. 648 4.3.3. Terminating Contexts 650 The update context request can be used to instruct the LS to 651 terminate a context. The "lifetime" element in the request is set to 652 a zero duration. Once the context has been terminated, or it has 653 expired, Location URIs that reference that context can no longer be 654 used and the Device MUST NOT use the Location URIs or password 655 relating to that context. 657 The LS MAY terminate a context without notifying the Device. The LS 658 SHOULD terminate contexts if it, or the LG, detect that any 659 information relating to the Device changes in a way that invalidates 660 the context. 662 When the Device requests that a context be terminated, the LG 663 responds with a "contextResponse" message that does not include any 664 context information; this message MUST include the HELD "201" 665 response code. 667 4.4. Combined Context and Location Requests 669 HELD supports an optimization that allows for the creation or update 670 of a context while simultaneously requesting location information. 671 The optional "location" attribute on the "createContext" or 672 "updateContext" request can be used to request that the LG include a 673 PIDF-LO in the "contextResponse". This PIDF-LO is formed according 674 to the profile details associated with the context. 676 4.5. Indicating Errors 678 In the event of an error, the LG SHOULD respond to the Device with an 679 error document. The error response applies to all request types and 680 SHOULD also be sent in response to any unrecognized request. 682 An error indication document consists of an "error" element. The 683 "error" element MUST include a "code" attribute that indicates the 684 type of error. A set of predefined error codes are included in 685 Section 5.8. 687 Error responses MAY also include a "message" attribute that can 688 include additional information. This information SHOULD be for 689 diagnostic purposes only, and MAY be in any language. The language 690 of the message SHOULD be indicated with an "xml:lang" attribute. 692 5. Protocol Parameters 694 This section describes, in detail the parameters that are used for 695 this protocol. Table 2 lists the top-level components used within 696 the protocol and where they are used. 698 +------------------------+-------------+-------------+--------------+ 699 | Parameter | Location | Create | Update | 700 | | Request | Context | Context | 701 +------------------------+-------------+-------------+--------------+ 702 | responseTime | Request | Request | Request | 703 | (Section 5.1) | | | | 704 | | | | | 705 | assert (Section 5.2) | Request | | | 706 | | | | | 707 | exact (assert) | Request | | | 708 | (Section 5.2.4) | | | | 709 | | | | | 710 | locationType | Request | | | 711 | (Section 5.3) | | | | 712 | | | | | 713 | exact (locationType) | Request | | | 714 | (Section 5.3.1) | | | | 715 | | | | | 716 | profile (Section 5.4) | Request | Request | Request | 717 | | | | | 718 | signed (Section 5.5) | Request | | | 719 | | | | | 720 | lifetime (Section 5.6) | | Request | Request | 721 | | | | | 722 | rules (Section 5.7) | | Request | Request | 723 | | | | | 724 | code (Section 5.8) | Error | Error & | Error & | 725 | | | Response | Response | 726 | | | | | 727 | message (Section 5.9) | Error | Error & | Error & | 728 | | | Response | Response | 729 | | | | | 730 | context (Section 5.10) | Request | Response | Request & | 731 | | | | Response | 732 | | | | | 733 | location | | Request | Request | 734 | (Section 5.11) | | | | 735 +------------------------+-------------+-------------+--------------+ 737 Table 2: Message Parameter Usage 739 5.1. "responseTime" Parameter 741 The "responseTime" attribute indicates to the LG how long the Device 742 is prepared to wait for a response. This attribute MAY be added to 743 any request message, although it is primarily used with the location 744 request. The value of this attribute is indicative only, the LG is 745 under no obligation to strictly adhere to the time limit implied; any 746 enforcement of the time limit is left to the Device. 748 This attribute MAY be either a duration value as defined in XML 749 Schema [W3C.REC-xmlschema-2-20041028], or a decimal seconds value, 750 which may include a decimal point. It is RECOMMENDED that systems 751 support millisecond precision for this parameter. 753 The LG SHOULD provide the most accurate LI that can be determined 754 within the specified interval. This parameter could be used as input 755 when selecting the method of location determination, where multiple 756 such methods exist. If this parameter is absent, then the LG SHOULD 757 return the most precise LI it is capable of determining. 759 5.2. "assert" Parameter 761 The "assert" element allows a Device to provide LI to the LG as part 762 of a location request. Two types of content are allowed: a geodetic 763 structure made up of a Geography Markup Language (GML) geometry 764 object, "_Geometry" as defined by [OGC.GML-3.1.1]; and a civic 765 address structure, "civicAddress" as defined by 766 [I-D.ietf-geopriv-revised-civic-lo]. The contents of this element 767 SHOULD follow the rules in [I-D.ietf-geopriv-pdif-lo-profile]. 769 When used in combination with the "context" element, this LI MAY be 770 used by the LS for requests to Location URIs for that context. 772 This element is mutually exclusive with the "locationType" parameter, 773 defined in Section 5.3. The type of LI requested is implied by the 774 types included in the assertion. 776 5.2.1. "method" Parameter 778 The "method" attribute SHOULD be attached to the "assert" element to 779 indicate the means by which the LI was derived. This attribute 780 follows the rules of the similarly named method element of the 781 PIDF-LO. 783 5.2.2. "timestamp" Parameter 785 The "timestamp" attribute SHOULD be attached to the "assert" element 786 to indicate when the LI was generated. 788 5.2.3. "expires" Parameter 790 The "expires" attribute MAY be attached to the "assert" element to 791 indicate when the included LI is no longer valid. The LG SHOULD set 792 the "retention-expires" element in the returned PIDF-LO to no later 793 than this time if it uses the LI. This attribute SHOULD NOT be 794 included unless this time is definite. 796 5.2.4. "exact" Parameter 798 When the "exact" attribute is set to "true", it indicates to the LG 799 that the contents of the "assert" parameter MUST be strictly 800 followed. The default value of "false" allows the LG the option of 801 ignoring these values. 803 This attribute indicates that the asserted LI MUST be included in the 804 PIDF-LO response. If the LG cannot do this for any reason, which is 805 usually because it determines that the LI was inaccurate or 806 insufficiently precise, the LG MUST indicate an error. 808 5.3. "locationType" Parameter 810 The "locationType" element is included in a location request. It 811 contains a list of LI types that are requested by the Device. The 812 following list describes the possible values: 814 any: The LG SHOULD attempt to provide LI in all forms available to 815 it. This value MUST be assumed as the default if no 816 "locationType" is specified. The LG SHOULD return location 817 information in a form that is suited for routing and responding to 818 an emergency call in its jurisdiction. 820 geodetic: The LG SHOULD return a geodetic location for the Target. 822 civic: The LG SHOULD return a civic address for the Target. Any 823 type of civic address may be returned. The LG SHOULD ignore this 824 value if a request for jurisdictional or postal civic address has 825 been made and can be satisfied. 827 jurisdictionalCivic: The LG SHOULD return a jurisdictional civic 828 address for the Target. 830 postalCivic: The LG SHOULD return a postal civic address for the 831 Target. 833 The "locationType" element is mutually exclusive with the "assert" 834 element, defined in Section 5.2. 836 The LG SHOULD return the requested location type or types. The LG 837 MAY provide additional location types, or it MAY provide alternative 838 types if the request cannot be satisfied for a requested location 839 type. If the "exact" attribute is present and set to "true" in a 840 location request, then a successful LG response MUST provide the 841 requested location type only, with no additional location 842 information. The "exact" attribute has no effect when this element 843 is set to "any". 845 The "SHOULD"-strength requirement on this parameter is included to 846 allow for soft-failover. This enables a fixed client configuration 847 that prefers a specific location type without causing location 848 requests to fail when that location type is unavailable. Unless the 849 "exact" attribute is set, the LG MUST provide LI in any available 850 form if it is unable to comply with the request. 852 For example, a notebook computer could be configured to retrieve 853 civic addresses, which is usually available from typical home or work 854 situations. However, when using a wireless modem, the LG might be 855 unable to provide a civic address. 857 5.3.1. "exact" Parameter 859 When the "exact" attribute is set to "true", it indicates to the LG 860 that the contents of the "locationType" parameter MUST be strictly 861 followed. The default value of "false" allows the LG the option of 862 ignoring these values. 864 A value of "true" indicates that the LG MUST provide a PIDF-LO that 865 includes LI of the requested type or types. The LG MUST provide the 866 requested types only and these types SHOULD be specified in the same 867 order as they were requested. The LG SHOULD handle an exact request 868 that includes a "locationType" element set to "any" as if the "exact" 869 attribute were set to "false". 871 5.4. "profile" Parameter 873 The "profile" element contains a presentity identifier [RFC2778] and 874 GEOPRIV usage rules [RFC4119] information. All fields are optional 875 within this element, but when these fields are included, the LG MUST 876 use these parameters when constructing the PIDF-LO document. 878 This element MAY be included in location requests, create context 879 requests and update context requests. When included in a location 880 request, the profile is used immediately; when used in create context 881 or update context requests, the profile is stored on the LS and is 882 provided to the LG when the LS responds to requests from LRs. 884 5.4.1. "presentity" Parameter 886 The "presentity" element contains a presentity identifier that the LG 887 SHOULD include in the "pres" attribute of the PIDF-LO document. 889 The LG MAY require authentication of the presentity through any 890 means; the LG SHOULD ignore this parameter if authentication 891 information is not present or authentication information cannot be 892 verified. 894 5.4.2. "retentionExpiry" Parameter 896 The "retentionExpiry" element contains an absolute "dateTime" 897 [W3C.REC-xmlschema-2-20041028] value for the "retention-expires" 898 element of the PIDF-LO usage rules. This element is mutually 899 exclusive with the "retentionInterval" element. 901 The LG MAY use a different value than that specified (or the 902 suggested default) as circumstances dictate, but MUST NOT use a value 903 later than specified. If this value indicates a time that has 904 already passed, the request MUST be rejected with an error. See 905 retentionInterval (Section 5.4.3) for more details. 907 5.4.3. "retentionInterval" Parameter 909 The "retentionInterval" element contains a time duration value that 910 is specified in the same fashion as the responseTime attribute 911 (Section 5.1). 913 This value MUST be added to the time at which the PIDF-LO document is 914 created to set the value of the "retention-expires" element. This 915 element enables the Target to set an interval over which a LR can 916 retain a LO, rather than an absolute time. This element is mutually 917 exclusive with the "retentionExpires" element. 919 If neither "retentionExpiry" nor "retentionInterval" are specified, 920 the LG SHOULD provide a default value for the "retention-expires" 921 element of the generated PIDF-LO document. The default for this 922 value SHOULD be 24 hours from the receipt of the location request as 923 defined in [RFC4119]. 925 The LG MAY use a different value than that specified (or the 926 suggested default) as circumstances dictate, but MUST NOT use a value 927 larger than specified. 929 5.4.4. "retransmission" Parameter 931 The "retransmission" element contains a boolean value that MUST be 932 included in the "retransmission-allowed" element of the generated 933 PIDF-LO usage rules. When this element is not provided, the LG MUST 934 set the "retransmission-allowed" element to "false". 936 5.4.5. "rulesetURI" Parameter 938 The "rulesetURI" element contains a URI value that MUST be included 939 in the "ruleset-reference" element of the generated PIDF-LO usage 940 rules. 942 This datum is only used to construct the usage rules in the PIDF-LO 943 document. Within the context of a profile, this ruleset is not 944 applied by either LG or LS, and the LS does not apply the rules found 945 at the URI. 947 5.5. "signed" Parameter 949 The "signed" attribute indicates whether the Device requires a 950 digitally signed PIDF-LO. When present and set to "true", the LG 951 MUST provide a PIDF-LO document that is signed according to XML- 952 Signature [RFC3275]. 954 5.6. "lifetime" Parameter 956 The "lifetime" element specifies the maximum time that a context 957 should be maintained by the LS. This parameter MUST be included in 958 the context creation request to indicate to the LS the latest time 959 that the context is allowed to be retained. The parameter MAY be 960 included in context update requests to modify this time; when 961 included in an update request with a zero value, it indicates that 962 the context MUST be removed immediately. 964 The "lifetime" element is a duration value that is specified in the 965 same fashion as the "responseTime" attribute. 967 This value MUST be added to the current time when received by the LS 968 to determine the time at which the context expires. An LS MAY use 969 any value less than or equal to this value, but MUST NOT use a longer 970 value. The actual expiry time of the context MUST be indicated in 971 the context response. 973 5.7. "rules" Parameter 975 The "rules" element contains the authorization policy of the Target 976 that dictates how and to whom LI is provided by the LS. This policy 977 MUST be applied by the LS when providing LI to LRs. 979 Authorization policies MUST conform to 980 [I-D.ietf-geopriv-common-policy]. If the authorization policy is 981 invalid, cannot be retrieved, or is otherwise not understood by the 982 LS, the LG SHOULD fail the request. Note that this implies that the 983 LS SHOULD attempt to retrieve an authorization policy that is 984 provided by-reference at the time of a create context request; 985 however, an LS MAY choose to do this later, if the requested response 986 time might be exceeded. 988 In the absence of an authorization policy, the LS MUST NOT provide LI 989 to any LR. Note that in certain jurisdictions an LS might be 990 required to provide LI to specific parties irrespective of the 991 authorization policy, as mandated by legislation; for example, 992 emergency services in some countries. 994 5.7.1. "rulesetURI" Parameter 996 The "rulesetURI" element contains a URI that references the Target's 997 authorization policy. This URI should reference a document of type 998 "application/auth-policy+xml" as defined in 999 [I-D.ietf-geopriv-common-policy]. 1001 It is RECOMMENDED that a ruleset URI use the "https" scheme. It is 1002 anticipated that, to improve responsiveness and reduce network usage, 1003 an LS could cache an authorization policy, consistent with the rules 1004 specified by the Rule Holder. For instance, the Rule Holder could 1005 specified retention times using the "Expires" header in HTTP 1006 [RFC2616]. The impact of changes to authorization policies are 1007 discussed in Section 4.3.2. 1009 5.7.2. Common Policy "ruleset" Parameter 1011 The "ruleset" element, which is in the 1012 "urn:ietf:params:xml:ns:common-policy" namespace 1013 [I-D.ietf-geopriv-common-policy], allows for providing an 1014 authorization policy directly as part of a request. 1016 5.8. "code" Parameter 1018 All responses, except a PIDF-LO document, MUST contain a response 1019 code. The "code" attribute applies to the "error" and 1020 "contextResponse" messages. 1022 The following response codes follow a three decimal form similar to 1023 that in HTTP [RFC2616] and SIP [RFC3261]: 1025 200 (Success): This code indicates that the request was successful. 1026 This code MUST not be used for an error response. 1028 201 (Context Terminated): This code indicates that the request to 1029 terminate a context was successful. 1031 400 (Request Error): This code indicates that the request was badly 1032 formed in some fashion. 1034 401 (XML Error): This code indicates that the XML content of the 1035 request was either badly formed or invalid. 1037 402 (Authentication Error): This code indicates that the request 1038 either did not contain authentication information, or the 1039 authentication provided was not accepted. 1041 403 (Asserted Location Error): This code indicates that the LI that 1042 was asserted in the request was not acceptable to the LG. This 1043 code is used when the "exact" attribute on the "assert" parameter 1044 is set to "true". 1046 404 (Context Not Found): This code indicates that the context 1047 identified in the request was not found. This code MAY also be 1048 used if the password provided was incorrect. 1050 500 (General LG Error): This code indicates that an unspecified 1051 error occurred at the LG. 1053 501 (Location Unknown): This code indicates that the LG could not 1054 determine the location of the Device. 1056 502 (Unsupported Message): This code indicates that the request was 1057 not supported or understood by the LG. 1059 503 (Timeout): This code indicates that the LG could not satisfy the 1060 request within the time specified in the "requestTime" parameter. 1062 504 (Cannot Provide LI Type): This code indicates that the LG was 1063 unable to provide LI of the type or types requested. This code is 1064 used when the "exact" attribute on the "locationType" parameter is 1065 set to "true". 1067 Additional response codes within the x00 to x79 range MUST be 1068 specified in published RFCs; the range from x80 to x99 is reserved 1069 for private usage. 1071 5.9. "message" Parameter 1073 The "contextResponse" and "error" messages MAY include a "message" 1074 attribute to convey some additional, human-readable information about 1075 the result of the request. This message MAY be included in any 1076 language, which SHOULD be indicated by the "xml:lang", attribute. 1078 5.10. "context" Parameter 1080 The "context" element includes information that is used to identify a 1081 context and control access to it. The context is identified by one 1082 or more Location URIs and a Device is granted a password which MUST 1083 be provided when accessing the context to update the information 1084 contained. 1086 When a context is created, the LG provides a "contextResponse" 1087 message that contains the "context" element. This element contains 1088 all of the Location URIs that can be used for the context, a 1089 password, and an expiry time. 1091 To update the details in a context, or reuse profile information 1092 stored in the context, the Device provides a "context" element. When 1093 identifying a context in this manner, the Device MUST provide only 1094 one Location URI and the password. 1096 5.10.1. "locationURI" Parameter 1098 The "locationURI" element includes a single Location URI. Each 1099 Location URI is allocated by the LS so that it is able to uniquely 1100 identify the context. 1102 A "contextResponse" message contains any number of "locationURI" 1103 elements. It is RECOMMENDED that the LS allocate a Location URI for 1104 all schemes that it supports and that no scheme is present twice. 1106 All "updateContext" request messages MUST contain only one 1107 "locationURI" element, which is all that is necessary to uniquely 1108 identify a context. The Device MAY select any of the Location URIs 1109 provided by the LS. Location URIs do not change over the lifetime of 1110 a context. 1112 5.10.2. "password" Parameter 1114 The "password" element carries a password that is used to access the 1115 context after it has been created. The LS generates this value when 1116 creating a context and the Device MUST use the exact same value when 1117 it wishes to access the context. This value acts as a shared secret 1118 between Device and LS. 1120 The value of the password MAY be updated in the response to any 1121 "updateContext" message. 1123 This element MAY contain any valid XML character data, within the 1124 constraints of the XML Schema "token" type. 1126 5.10.3. "expires" Parameter 1128 The "expires" attribute indicates the time at which the context 1129 created by the LS will expire. This attribute is included in the 1130 "contextResponse" message only. 1132 Responses to create and update context requests MUST include the 1133 expiry time of the context. If the LS has expired a context in 1134 response to an update context request, this value SHOULD include a 1135 time in the past to avoid problems that could be caused by a slow 1136 clock in the Device. 1138 5.11. "location" Parameter 1140 The "location" parameter is a boolean attribute associated with the 1141 "createContext" or "updateContext" message. The default for this 1142 attribute is "false". 1144 This parameter, when present and set to "true" indicates that the LG 1145 SHOULD include a PIDF-LO document in the "contextResponse" message. 1146 The success of any request that includes this parameter MUST NOT be 1147 affected by any error in providing a location; thus, if the LG is 1148 unable to include a PIDF-LO, it is only omitted from the response. 1149 If a "contextResponse" does not include a PIDF-LO, the Device can 1150 determine the reasons for failure by sending a separate 1151 "locationRequest". 1153 6. XML Schema 1155 This section gives the XML Schema Definition 1156 [W3C.REC-xmlschema-1-20041028] of the "application/held+xml" format. 1157 This is presented as a formal definition of the "application/ 1158 held+xml" format. Note that the XML Schema definition is not 1159 intended to be used with on-the-fly validation of the presence XML 1160 document. 1162 1163 1176 1177 1178 1180 This document defines HELD messages. 1181 1182 1184 1185 1186 1188 1189 1190 1192 1193 1194 1195 1196 1197 1199 1200 1201 1203 1204 1205 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1234 1235 1236 1237 1238 1240 1241 1243 1245 1246 1248 1250 1251 1252 1253 1255 1256 1257 1258 1259 1260 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1285 1286 1287 1288 1290 1291 1292 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1310 1311 1312 1314 1315 1316 1317 1318 1319 1321 1322 1323 1324 1325 1326 1328 1329 1330 1332 1333 1334 1335 1336 1338 1340 1341 1342 1343 1344 1346 1347 1348 1349 1350 1351 1352 1354 1356 1358 1359 1361 1362 1363 1365 1367 1368 1369 1370 1371 1372 1374 1375 1376 1377 1378 1380 1383 1384 1385 1386 1387 1388 1389 1391 1393 1395 1397 1398 1400 1401 1402 1404 1406 1408 1409 1410 1411 1412 1413 1414 1416 1418 1419 1420 1421 1423 1424 1426 1427 1429 1430 1431 1433 1436 1438 7. HTTP Binding 1440 This section defines an HTTP [RFC2616] binding for this protocol, 1441 which all conforming implementations MUST support. This binding 1442 takes the form of a Web Service (WS) that can be described by the Web 1443 Services Description Language (WSDL) document in Section 7.1. 1445 The three request messages are carried in this binding as the body of 1446 an HTTP POST request. The MIME type of both request and response 1447 bodies should be "application/held+xml", except that a PIDF-LO 1448 document SHOULD have the MIME type "application/pidf+xml". 1450 The LG populates the HTTP headers so that they are consistent with 1451 the contents of the message. In particular, the "Expires" and cache 1452 control headers are used to control the caching of any PIDF-LO 1453 document. The HTTP status code SHOULD have the same first digit as 1454 any "contextResponse" or "error" body included, and it SHOULD 1455 indicate a 2xx series response when a PIDF-LO document is included. 1457 This binding also includes a default behaviour, which is triggered by 1458 a GET request, or a POST with no request body. If either of these 1459 queries are received, the LG MUST attempt to provide a PIDF-LO 1460 document, as if the request was a location request. 1462 This binding MUST use TLS as described in [RFC2818]. TLS provides 1463 message integrity and privacy between Device and LG. The LG MUST use 1464 the server authentication method described in [RFC2818]; the Device 1465 MUST fail a request if server authentication fails, except in the 1466 event of an emergency. 1468 7.1. HTTP Binding WSDL 1470 The following WSDL 2.0 [W3C.CR-wsdl20-20060106] document describes 1471 the HTTP binding for this protocol. Actual service instances MUST 1472 provide a "service" with at least one "endpoint" that implements the 1473 "heldHTTP" binding. A service description document MAY include this 1474 schema directly or by using the "import" or "include" directives. 1476 1477 1486 1487 This document describes the basic HELD web service. 1488 Please refer to RFCXXXX for details. 1489 [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number 1490 for this specification and remove this note.]] 1491 1493 1494 1495 1497 1498 1499 1501 1503 1504 1505 1506 1507 1509 1510 1511 1512 1513 1515 1516 1517 1518 1519 1521 1524 1525 1526 1528 1530 1531 1535 1539 1544 1550 1552 1554 8. Security Considerations 1556 The threat model for this protocol assumes that the LG exists within 1557 the same administrative domain as the Device. The LG requires access 1558 to network information so that it can determine LI. Therefore, the 1559 LG can use network information to protect against a number of the 1560 possible attacks. 1562 An in-depth discussion of the security considerations applicable to 1563 the use of Location URIs and by-reference provision of LI is included 1564 in [I-D.winterbottom-location-uri]. 1566 8.1. Return Routability 1568 It is RECOMMENDED that Location Generators use return routability 1569 rather than requiring Device authentication. Device authentication 1570 SHOULD NOT be required due to the administrative challenge of issuing 1571 and managing of client credentials, particularly when networks allow 1572 visiting users to attach devices. However, the LG MAY require any 1573 form of authentication as long as these factors are considered, in 1574 particular see Section 6.3.2 of [I-D.winterbottom-location-uri]. 1576 Addressing information used in a request to the LG is used to 1577 determine the identity of the Device, and to address a response. 1578 This ensures that a Device can only request its own LI. 1580 A temporary spoofing of IP address could mean that a device could 1581 request a Location URI that would result in another Device's 1582 location. One or more of the follow approaches are RECOMMENDED to 1583 limit this exposure: 1585 o Location URIs SHOULD have a limited lifetime, that is, the LG 1586 SHOULD enforce a maximum value for the lifetime element 1587 (Section 5.6). 1589 o The network SHOULD have mechanisms that protect against IP address 1590 spoofing. 1592 o The LG SHOULD ensure that requests can only originate from within 1593 its administrative domain. 1595 o The LG and network SHOULD be configured so that the LG is made 1596 aware of Device movement within the network and addressing 1597 changes. If the LG and LS detect a change in the network that 1598 invalidates a context, the context MUST be terminated. 1600 The above measures are dependent on network configuration and SHOULD 1601 be considered with circumstances in mind. For instance, in a fixed 1602 internet access providers may be able to restriction the allocation 1603 of IP addresses to a single physical line, ensuring that spoofing is 1604 not possible; in such an environment, the other measures are not 1605 necessary. 1607 An identity association can also be used to guard against the theft 1608 of a Location URI, as described in [I-D.winterbottom-location-uri]. 1610 8.2. Transaction Layer Security 1612 All bindings for this protocol MUST ensure that messages are 1613 adequately protected against eavesdropping and modification. 1614 Bindings MUST also provide a means of authenticating the LG. 1616 It is RECOMMENDED that all bindings also use TLS [RFC2246]. 1618 For the HTTP binding, TLS MUST be used. TLS provides protection 1619 against eavesdropping and modification. The server authentication 1620 methods described in HTTP on TLS [RFC2818] MUST be used. 1622 8.3. Veracity of Asserted LI 1624 The assert element (Section 5.2) allows a Device the ability to 1625 provide LI. However, if an LG uses asserted LI, it is the LG that 1626 becomes responsible for the veracity of that information. Therefore, 1627 when the Device provides LI in a request, the LG MUST NOT use this 1628 information unless it can ensure its accuracy. This prevents the 1629 fraudulent provision of LI that could be caused by the LG accepting 1630 LI without any checks. 1632 It is unlikely that an LG is able to verify Device-provided LI beyond 1633 any uncertainty. The ability of an LG to verify LI is limited by its 1634 own capacity to determine the location of the Device. The LG SHOULD 1635 indicate the source of LI using the PIDF-LO "method" parameter so 1636 that users of LI can make appropriate judgments on its veracity. 1638 9. Examples 1640 9.1. Simple HTTP Binding Example Messages 1642 The examples in this section show a complete HTTP message that 1643 includes the HELD request or response document. 1645 This example shows the most basic request for a LO. This uses the 1646 GET feature described by the HTTP binding. This example assumes that 1647 the LG service exists at the URL "https://lg.example.com/location". 1649 GET /location HTTP/1.1 1650 Host: lg.example.com 1651 Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, 1652 text/xml;q=0.7 1653 Accept-Charset: UTF-8,* 1655 The GET request is exactly identical to a minimal POST request that 1656 includes an empty "locationRequest" element. 1658 POST /location HTTP/1.1 1659 Host: lg.example.com 1660 Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, 1661 text/xml;q=0.7 1662 Accept-Charset: UTF-8,* 1663 Content-Type: application/held+xml 1664 Content-Length: 87 1666 1667 1668 The successful response to either of these requests is a PIDF-LO 1669 document. The following response shows a minimal PIDF-LO response. 1671 HTTP/1.x 200 OK 1672 Server: Example LG 1673 Date: Tue, 10 Jan 2006 03:42:29 GMT 1674 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1675 Cache-control: private 1676 Content-Type: application/pidf+xml 1677 Content-Length: 594 1679 1680 1682 1683 1684 1685 1686 1688 -34.407 150.88001 1689 1690 1691 1692 1693 2006-01-11T03:42:28+00:00 1694 1695 1696 1697 2006-01-10T03:42:28+00:00 1698 1699 1701 The error response to either of these requests is an error document. 1702 The following response shows an example error response. 1704 HTTP/1.x 500 Server Error 1705 Server: Example LG 1706 Date: Tue, 10 Jan 2006 03:49:20 GMT 1707 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1708 Cache-control: private 1709 Content-Type: application/held+xml 1710 Content-Length: 135 1712 1713 1716 Note: To focus on important portions of messages, all examples 1717 following this note do not show HTTP headers or the XML prologue. 1718 In addition, sections of XML not relevant to the example are 1719 replaced with comments. 1721 9.2. Location Request Examples 1723 The location request shown below specifies location types and 1724 provides a profile that the LG applies to the PIDF-LO document. The 1725 request specifies that a response is desired within 10.5 seconds. 1727 1729 1730 jurisdictionalCivic 1731 geodetic 1732 1733 1734 pres:user@example.com 1735 1800 1736 false 1737 https://example.com/~user/ruleset.xml 1738 1739 1740 The response to this location request is the following PIDF-LO 1741 document, which shows how the profile values are applied. 1743 1745 1746 1747 1748 1749 1751 1752 1753 1754 1755 1756 1757 1758 false 1759 1760 2006-01-11T03:42:28+00:00 1761 1762 https://example.com/~user/ruleset.xml 1763 1764 1765 1766 1767 2006-01-10T03:42:28+00:00 1768 1769 1770 The following location request includes a location assertion that 1771 includes a user-provided civic address. This message also requests 1772 that the LG retrieve profile information from a context that exists 1773 on an LS. 1775 1777 1778 1781 1782 1783 1784 1785 1786 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1787 1788 vs76e8cae9873a079888p9y4txwa 1789 1790 1792 Since this request includes the "exact" parameter set to "true", any 1793 successful response MUST include the provided LI. 1795 9.3. Context Creation and Update Examples 1797 The following create context request shows the simplest form of this 1798 message, which sets a two hour lifetime on the context and includes a 1799 "rulesetURI" element for the LS. 1801 1802 PT2H 1803 1804 1805 https://www.example.com/~user/privacy/ruleset.xml 1806 1807 1808 1809 The following more complex create context request includes additional 1810 information. This includes a profile that sets the presentity and 1811 some of the "usage-rules" components in the PIDF-LO that the LS 1812 serves. 1814 1815 PT2H 1816 1817 pres:user@example.com 1818 2006-01-13T12:00:00+00:00 1819 false 1820 1821 1822 1823 https://www.example.com/~user/privacy/ruleset.xml 1824 1825 1826 1828 A typical successful response to this message provides several 1829 Location URIs in different schemes (in this case: "https" and 1830 "sips"), the exact context expiry time, and a password that can be 1831 used to update the context. 1833 1835 1836 1837 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1838 1839 1840 sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 1841 1842 38cdj38mjcd-0-=54821kj28mp1qms.1 1843 1844 1846 If any aspect of the data stored in a context changes, a 1847 "contextUpdate" request is sent to the LG to request that it update 1848 the information. This request includes the information necessary to 1849 access a context (the location URI and password) and only the 1850 information that has changed. 1852 The following request demonstrates how information stored in a 1853 context could be updated. For the context previously created, this 1854 provides the "retentionInterval" element, which overrides a 1855 previously configured "retentionExpiry" value. 1857 1859 1860 1861 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1862 1863 38cdj38mjcd-0-=54821kj28mp1qms.1 1864 1865 1866 600 1867 1868 1870 To indicate success, the LG provides a "contextResponse" identical in 1871 form to the original request. 1873 The following request shows that a context lifetime can be extended 1874 or shortened by the Device by updating a context with a new 1875 "lifetime" element. The following message requests that the LS 1876 maintain the context for two hours beyond the current time. 1878 1879 1880 1881 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1882 1883 38cdj38mjcd-0-=54821kj28mp1qms.1 1884 1885 PT2H 1886 1887 The response to a request to extend the context includes the new 1888 expiry time of the context, if it has changed. 1890 1892 1893 1894 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1895 1896 1897 sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 1898 1899 38cdj38mjcd-0-=54821kj28mp1qms.1 1900 1901 1903 A zero value for the "lifetime" element terminates the context. The 1904 following request terminates the context. 1906 1907 1908 1909 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1910 1911 38cdj38mjcd-0-=54821kj28mp1qms.1 1912 1913 PT0S 1914 1916 The response to a message that requests the termination of a context 1917 appears as follows. 1919 1922 9.4. Sample LG WSDL Document 1924 The following WSDL document demonstrates how a WSDL document can be 1925 created for a specific service, in this case, a service at the URI 1926 "https://lg.example.com/location". 1928 1929 1934 1937 1938 1941 1943 1945 10. IANA Considerations 1947 According to the guidelines in [RFC3688], this document calls for an 1948 IANA registry for result codes and registers an XML namespace and 1949 schema. It also registers the "application/held+xml" MIME type. 1951 10.1. IANA Registry for HELD Result Codes 1953 IANA will establish and maintain a registry of HELD result codes. 1954 Additional values are registered based on the "specification 1955 required" option in [RFC3688]. 1957 Specifications MUST specify the following information when 1958 registering new values in this registry: 1960 Code Value: A three-digit value from 000 to 679. The last 20 codes 1961 in each block of 100 (from x80 to x99) are reserved for private or 1962 experimental use and cannot be registered. 1964 Short Message: A brief message that describes the general reason for 1965 the code. 1967 Publication: A reference to any relevant publication or 1968 specification. 1970 Description and Usage: A longer description of the code and the 1971 circumstances where it applies. This description does not need to 1972 be exhaustive. 1974 The values in Section 5.8 are pre-registered in this registry. 1976 10.2. URN Sub-Namespace Registration for 1977 urn:ietf:params:xml:ns:geopriv:held 1979 This section registers a new XML namespace, 1980 "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in 1981 [RFC3688]. 1983 URI: urn:ietf:params:xml:ns:geopriv:held 1985 Registrant Contact: IETF, GEOPRIV working group, 1986 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1988 XML: 1990 BEGIN 1991 1992 1994 1995 1996 HELD Messages 1997 1998 1999

Namespace for HELD Messages

2000

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

2001 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2002 with the RFC number for this specification.]] 2003

See RFCXXXX.

2004 2005 2006 END 2008 10.3. XML Schema Registration 2010 This section registers an XML schema as per the guidelines in 2011 [RFC3688]. 2013 URI: urn:ietf:params:xml:schema:geopriv:held 2015 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2016 Martin Thomson (martin.thomson@andrew.com). 2018 Schema: The XML for this schema can be found as the entirety of 2019 Section 6 of this document. 2021 10.4. URN Sub-Namespace Registration for 2022 urn:ietf:params:xml:ns:geopriv:held:http 2024 This section registers a new XML namespace, 2025 "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in 2026 [RFC3688]. 2028 URI: urn:ietf:params:xml:ns:geopriv:held:http 2030 Registrant Contact: IETF, GEOPRIV working group, 2031 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2033 XML: 2035 BEGIN 2036 2037 2039 2040 2041 HELD HTTP Binding WS 2042 2043 2044

Namespace for HELD HTTP Binding WS

2045

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

2046 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2047 with the RFC number for this specification.]] 2048

See RFCXXXX.

2049 2050 2051 END 2053 10.5. MIME Media Type Registration for 'application/held+xml' 2055 This section registers the "application/held+xml" MIME type. 2057 To: ietf-types@iana.org 2059 Subject: Registration of MIME media type application/held+xml 2061 MIME media type name: application 2063 MIME subtype name: held+xml 2065 Required parameters: (none) 2067 Optional parameters: charset 2068 Indicates the character encoding of enclosed XML. Default is 2069 UTF-8. 2071 Encoding considerations: Uses XML, which can employ 8-bit 2072 characters, depending on the character encoding used. See RFC 2073 3023 [RFC3023], section 3.2. 2075 Security considerations: This content type is designed to carry 2076 protocol data related to the location of an entity, which could 2077 include information that is considered private. Appropriate 2078 precautions should be taken to limit disclosure of this 2079 information. 2081 Interoperability considerations: This content type provides a basis 2082 for a protocol 2084 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2085 replace XXXX with the RFC number for this specification.]] 2087 Applications which use this media type: Location information 2088 providers and consumers. 2090 Additional Information: Magic Number(s): (none) 2091 File extension(s): .xml 2092 Macintosh File Type Code(s): (none) 2094 Person & email address to contact for further information: Martin 2095 Thomson 2097 Intended usage: LIMITED USE 2099 Author/Change controller: This specification is TBD 2101 Other information: This media type is a specialization of 2102 application/xml [RFC3023], and many of the considerations 2103 described there also apply to application/held+xml. 2105 11. References 2107 11.1. Normative References 2109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2110 Requirement Levels", BCP 14, RFC 2119, March 1997. 2112 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2113 RFC 2246, January 1999. 2115 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2116 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2117 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2119 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2121 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 2122 Language) XML-Signature Syntax and Processing", RFC 3275, 2123 March 2002. 2125 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2126 January 2004. 2128 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 2129 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 2131 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2132 Format", RFC 4119, December 2005. 2134 [I-D.ietf-geopriv-revised-civic-lo] 2135 Thomson, M. and J. Winterbottom, "Revised Civic Location 2136 Format for PIDF-LO", 2137 draft-ietf-geopriv-revised-civic-lo-04 (work in progress), 2138 September 2006. 2140 [I-D.ietf-geopriv-pdif-lo-profile] 2141 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 2142 Considerations and Recommendations", 2143 draft-ietf-geopriv-pdif-lo-profile-04 (work in progress), 2144 May 2006. 2146 [I-D.winterbottom-geopriv-held-dhcp-discovery] 2147 Winterbottom, J. and M. Thomson, "HELD Service Discovery 2148 using DHCP", 2149 draft-winterbottom-geopriv-held-dhcp-discovery-00 (work in 2150 progress), October 2006. 2152 [I-D.thomson-geopriv-held-unaptr] 2153 Thomson, M. and J. Winterbottom, "U-NAPTR Discovery for 2154 HELD Services", draft-thomson-geopriv-held-unaptr-00 (work 2155 in progress), October 2006. 2157 [W3C.REC-xmlschema-2-20041028] 2158 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2159 Second Edition", World Wide Web Consortium 2160 Recommendation REC-xmlschema-2-20041028, October 2004, 2161 . 2163 [OGC.GML-3.1.1] 2164 Cox, S., Daisey, P., Lake, R., Portele, C., and A. 2165 Whiteside, "Geographic information - Geography Markup 2166 Language (GML)", OpenGIS 03-105r1, April 2004, 2167 . 2170 11.2. Informative References 2172 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2173 RFC 793, September 1981. 2175 [RFC2222] Myers, J., "Simple Authentication and Security Layer 2176 (SASL)", RFC 2222, October 1997. 2178 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 2179 Presence and Instant Messaging", RFC 2778, February 2000. 2181 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2182 Types", RFC 3023, January 2001. 2184 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 2185 RFC 3080, March 2001. 2187 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2188 A., Peterson, J., Sparks, R., Handley, M., and E. 2189 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2190 June 2002. 2192 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2193 Resource Identifier (URI): Generic Syntax", STD 66, 2194 RFC 3986, January 2005. 2196 [I-D.ietf-geopriv-common-policy] 2197 Schulzrinne, H., "Common Policy: A Document Format for 2198 Expressing Privacy Preferences", 2199 draft-ietf-geopriv-common-policy-11 (work in progress), 2200 August 2006. 2202 [I-D.winterbottom-location-uri] 2203 Winterbottom, J., "Rationale for Location by Reference", 2204 draft-winterbottom-location-uri-01 (work in progress), 2205 January 2006. 2207 [W3C.REC-xmlschema-1-20041028] 2208 Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, 2209 "XML Schema Part 1: Structures Second Edition", World Wide 2210 Web Consortium Recommendation REC-xmlschema-1-20041028, 2211 October 2004, 2212 . 2214 [W3C.REC-soap12-part1-20030624] 2215 Gudgin, M., Nielsen, H., Hadley, M., Mendelsohn, N., and 2216 J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", 2217 World Wide Web Consortium Recommendation REC-soap12-part1- 2218 20030624, June 2003, 2219 . 2221 [W3C.REC-soap12-part2-20030624] 2222 Nielsen, H., Hadley, M., Mendelsohn, N., Moreau, J., and 2223 M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 2224 Web Consortium Recommendation REC-soap12-part2-20030624, 2225 June 2003, 2226 . 2228 [W3C.CR-wsdl20-20060106] 2229 Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, 2230 "Web Services Description Language (WSDL) Version 2.0 Part 2231 1: Core Language", W3C CR CR-wsdl20-20060106, 2232 January 2006. 2234 Appendix A. Acknowledgements 2236 The authors would like to thank the following people for their 2237 contribution to this document (in alphabetical order): Nadine Abbott, 2238 Guy Caron, Martin Dawson, Jerome Grenier, Neil Justusson, Tat Lam, 2239 Patti McCalmont, Perry Prozeniuk, John Schnizlein, Henning 2240 Schulzrinne, Ed Shrum, and Hannes Tschofenig. 2242 Authors' Addresses 2244 James Winterbottom 2245 Andrew 2246 PO Box U40 2247 Wollongong University Campus, NSW 2500 2248 AU 2250 Phone: +61 2 4221 2938 2251 Email: james.winterbottom@andrew.com 2252 URI: http://www.andrew.com/ 2254 Martin Thomson 2255 Andrew 2256 PO Box U40 2257 Wollongong University Campus, NSW 2500 2258 AU 2260 Phone: +61 2 4221 2915 2261 Email: martin.thomson@andrew.com 2262 URI: http://www.andrew.com/ 2264 Barbara Stark 2265 BellSouth 2266 Room 7A41 2267 725 W Peachtree St. 2268 Atlanta, GA 30308 2269 US 2271 Email: barbara.stark@bellsouth.com 2273 Full Copyright Statement 2275 Copyright (C) The Internet Society (2006). 2277 This document is subject to the rights, licenses and restrictions 2278 contained in BCP 78, and except as set forth therein, the authors 2279 retain all their rights. 2281 This document and the information contained herein are provided on an 2282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2284 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2285 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2289 Intellectual Property 2291 The IETF takes no position regarding the validity or scope of any 2292 Intellectual Property Rights or other rights that might be claimed to 2293 pertain to the implementation or use of the technology described in 2294 this document or the extent to which any license under such rights 2295 might or might not be available; nor does it represent that it has 2296 made any independent effort to identify any such rights. Information 2297 on the procedures with respect to rights in RFC documents can be 2298 found in BCP 78 and BCP 79. 2300 Copies of IPR disclosures made to the IETF Secretariat and any 2301 assurances of licenses to be made available, or the result of an 2302 attempt made to obtain a general license or permission for the use of 2303 such proprietary rights by implementers or users of this 2304 specification can be obtained from the IETF on-line IPR repository at 2305 http://www.ietf.org/ipr. 2307 The IETF invites any interested party to bring to its attention any 2308 copyrights, patents or patent applications, or other proprietary 2309 rights that may cover technology that may be required to implement 2310 this standard. Please address the information to the IETF at 2311 ietf-ipr@ietf.org. 2313 Acknowledgment 2315 Funding for the RFC Editor function is provided by the IETF 2316 Administrative Support Activity (IASA).