idnits 2.17.00 (12 Aug 2021) /tmp/idnits44349/draft-tschofenig-geopriv-http-using-protocol-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 699. 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 (July 2, 2007) is 5430 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '15' is defined on line 629, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2818 (ref. '6') ** Obsolete normative reference: RFC 3825 (ref. '7') (Obsoleted by RFC 6225) ** Obsolete normative reference: RFC 2617 (ref. '9') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 == Outdated reference: A later version (-02) exists of draft-marshall-geopriv-lbyr-requirements-01 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track H. Schulzrinne 5 Expires: January 3, 2008 Columbia University 6 July 2, 2007 8 A GEOPRIV HTTPS Using Protocol 9 draft-tschofenig-geopriv-http-using-protocol-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an approach to to use Hypertext Transfer 43 Protocol (HTTP) over Transport Layer Protocol (TLS) to transport 44 Presence Information Data Format Location Objects (PIDF-LO) (see RFC 45 4119). It is a GEOPRIV using protocol as described in Section 5.2 or 46 RFC 3693 to resolve an identifier, which denotes a reference, to a 47 PIDF-LO. The document assumes that the HTTP client possesses the 48 reference that is obtained using a mechanism that are outside the 49 scope of this document and conveys it to the HTTP server in order to 50 retrieve a PIDF-LO in a response. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 56 3. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 8 58 5. Structure of Authorization Documents . . . . . . . . . . . . . 9 59 5.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.2. Matching with GEOPRIV Using Protocol Requirements . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 66 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 9.1. Steps for publication . . . . . . . . . . . . . . . . . . 19 68 9.1.1. The client uses HTTPS to connect to the server . . . . 19 69 9.1.2. The client authenticates to the server . . . . . . . . 19 70 9.1.3. The client publishes the resource . . . . . . . . . . 19 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . . . 23 77 1. Introduction 79 This document describes a strawman approach for HTTP [2] to transport 80 PIDF-LO objects [3]. RFC 3693 [4], Section 5.2 says the following 81 about Geopriv transport protocols: 83 "A protocol that just transports the LO as a string of bits, 84 without looking at them (like an IP storage protocol could do), is 85 not a using protocol, but only a transport protocol. 86 Nevertheless, the entity or protocol that caused the transport 87 protocol to move the LO is responsible for the appropriate 88 distribution, protection, usage, retention, and storage of the LO 89 based on the rules that apply to that LO." 91 While it might be possible to describe HTTP as a transport protocol 92 and punt all of the requirements to the layer above HTTP, this 93 document describes a layering of HTTP over TLS in use between client 94 and server, so that a common set of mechanisms for privacy and 95 authentication are established. 97 A usage scenario envisioned by this document is described in 98 Figure 1. 100 UA Alice SIP Proxy UAS-A UAS-B UAS-C 102 | SIP Message | | | | 103 |---------------------------->| | | | 104 | | SIP Message + LbyR | 105 | |------------------------->| 106 | | | 107 | | | 108 | | Resolve LbyR | 109 | |<=========================| 110 | | | 111 | | PIDF-LO | 112 | |=========================>| 113 | | | 114 | SIP Message | 115 |<-------------------------------------------------------| 116 | | 117 | | 119 Figure 1: Usage Scenario: Proxy adding Reference 121 Another usage scenario addressed by this document is described in 122 Figure 2. 124 UA Alice LCS UAS-A UAS-B UAS-C 126 | Request Reference | | | | 127 |---------------------------->| | | | 128 | Reference-to-LocationInfo | | | | 129 |<----------------------------| | | | 130 | | | | | 131 | SIP Message including Reference-to-LocationInfo | 132 |------------------------------------------------------->| 133 | | | 134 | | HTTPS GET with Reference | 135 | |<=========================| 136 | | | 137 | | PIDF-LO over HTTPS | 138 | |=========================>| 139 | | 140 | SIP Message | 141 |<-------------------------------------------------------| 142 | | 143 | | 145 Figure 2: Usage Scenario: End Host adding Reference 147 The scenario presented in Figure 2 describes a SIP User Agent Alice 148 using a reference to location information obtained using the Location 149 Configuration Protocol (LC), such as HELD [11], RELO [13] or 150 LocationRef [12]. This reference is then added to the SIP message to 151 a SIP message (as described in [14]). The SIP message travels from 152 the Alice via the SIP proxy to UAS-C whereby the reference might be 153 protected using S/MIME. 155 When UAS-C receives a SIP message with an included reference then it 156 resolves the reference to a PIDF-LO using the HTTPS mechanism 157 specified in this document. 159 2. Requirements Notation 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [1]. 165 This document furthermore uses the terminology defined in [4]. 167 3. Threat Models 169 HTTP can be used as a substrate to a number of different 170 applications, and defining a set of guidelines for conveying a 171 PIDF-LO for any application which might use HTTP would be difficult 172 or impossible. This document does not attempt that task. Instead, 173 it is limited in applicability to the case where a client uses an 174 HTTP GET request to retrieve a PIDF-LO object from a server. No 175 other functionality is covered. This document does not describe how 176 you would determine the URI of the PIDF-LO document or the 177 appropriate server to query. 179 This document assumes that the reference contains a random component 180 and does not contain identity information as outlined in [16]. 182 There are three threat models that need to be described: 184 Authorization Policy Threat Model: 186 The assumption here is that the HTTP server also has has some 187 authorization policies and is therefore able to control access to 188 these policies. Consequently, when the reference is conveyed to 189 the potential Location Recipient (e.g., via SIP [14]), then it 190 does not need to be protected (neither hop-by-hop nor end-to-end). 191 Authentication by the Location Recipient is needed (e.g., TLS 192 client authentication, HTTP Digest authenticatio, etc.) to 193 disclose location information only to authorized entities. 195 End-to-End Threat Model: 197 In this threat model we assume that the reference is encryped end- 198 to-end, for example using S/MIME and an adversay is not able to 199 eavesdrop, modify or replay a reference. Storing authorization 200 policies at the Location Server is not necessary since the end 201 host is able to control the disclosure of the PIDF-LO by making it 202 available only to trusted entities. Consequently, only the entity 203 that is able to decrypt the end-to-end protected object (in our 204 case the S/MIME encrypted object) can use the reference to resolve 205 it to a PIDF-LO. 207 Hop-by-Hop Threat Model: 209 This threat model assumes the reference can either be directly 210 communication between the Target and the Location Recipient or 211 that involved proxies are trusted. In some cases this threat 212 model is also applicable the reference is conveyed to multiple 213 Location Recipients (such as intermediaries and the final 214 communication end point as it is true for location-based routing). 215 The party that sees the reference has to be able to resolve it 216 into a PIDF-LO. 218 The first threat model requires client authentication and therefore 219 we describe a mechanism to apply the Geopriv authorization policy 220 framework (see [5] and [10]) to HTTP. 222 4. Steps for Retrieval 224 1. The client uses HTTPS [6] to connect to the server. 226 2. The client establishes an HTTPS connection to the server, as 227 described in RFC 2818. At the TLS layer, the use of 228 TLS_NULL_WITH_NULL_NULL MUST NOT be used as the CipherSuite. 230 3. The client authenticates to the server. 232 4. The client retrieves the resource. The client retrieves the 233 PIDF-LO resource using an HTTP GET request. 235 5. Structure of Authorization Documents 237 An authorization document is an XML document, formatted according to 238 the schema defined in [5]. The authorization documents used by this 239 document inherit the MIME type of common policy documents, 240 application/auth-policy+xml. As described in [5], an authorization 241 document is composed of rules which contain three parts - conditions, 242 actions, and transformations. Each action or transformation, which 243 is also called a permission, has the property of being a positive 244 grant of information to a Location Recipient. As a result, there is 245 a well-defined mechanism for combining actions and transformations 246 obtained from several sources. This mechanism is privacy safe, since 247 the lack of any action or transformation can only result in less 248 information being presented to a watcher. 250 This section describes how the identity and sphere elements are 251 instantiated. No new conditions, actions and transformations are 252 defined. 254 5.1. Conditions 256 5.1.1. Identity 258 Although the element is defined in [5], that specification 259 indicates that the specific usages of the framework document need to 260 define details that are protocol and usage specific. In particular, 261 it is necessary for a usage of the Common Policy framework to: 263 o Define acceptable means of authentication. 265 o Define the procedure for representing the identity of the WR 266 (Watcher/Requestor) as a URI or a IRI [8]. 268 5.1.1.1. Acceptable Forms of Authentication 270 A request is considered authenticated if one of the following 271 techniques is used: 273 HTTP Digest: 275 The presence agent has authenticated the Location Recipient using 276 HTTP digest authentication [9]. 278 TLS Authentication: 280 [[Editor's Note: More complex description since the different 281 identities used for TLS authentication need to be mapped to a URI 282 or a IRI. ]] 284 Identity Condition within a SAML Assertion: 286 TBD 288 Since HTTP Basic authentication is not recommended it is not 289 described above. 291 5.1.1.2. Computing a URI for the Location Recipient 293 For requests that are authenticated using HTTP Digest, the identity 294 of the Location Recipient is set equal to the concatenation of the 295 following case-sensitive items in the given order: 297 1. the scheme https to 'https:' 299 2. the content of the username parameter (i.e., username-value) of 300 the as carried in the Authorization Request Header as defined in 301 Section 3.2.2 of [9] 303 3. '@' token 305 4. The content of the realm parameter. Note that the realm 306 parameter MUST be chosen in such a way that it does not contain 307 '@' token. [[Editor's note: Alternatively, we could relax this 308 restriction and determine whether it would be OK to use ':' 309 instead of '@' for concatenation. As an example, this would lead 310 to examples like Mufasa:myhost@testrealm.com]] 312 The concatenated parameters are alwyas a URI since the username 313 parameter is a URI as specified in and the realm parameter is also a 314 URI with the above-mentioned constraint. Consider the following 315 example and the respective result-URI. 317 digest username: alice 318 digest realm: example.com 319 URI: https:alice@example.com 321 5.1.2. Sphere 323 The element is defined in [5]. However, each application 324 making use of the common policy specification needs to determine how 325 the presence server computes the value of the sphere to be used in 326 the evaluation of the condition. 328 This document does not provide an instantiation of the 329 element. Hence, the element is not present in an 330 authorization policy document defined in this document. 332 5.2. Matching with GEOPRIV Using Protocol Requirements 334 This section compares the GEOPRIV requirements described in [4] with 335 the approach outlined in this document. 337 Section 7.1 of [4] details the requirements of a "Location Object". 338 We discuss these requirements in the subsequent list. 340 Req. 1. (Location Object generalities): 342 * Regarding requirement 1.1, the Location Object has to be 343 understood by the Location Recipient and the Location Server, 344 the two communication end points. The PIDF-LO [3] allows both 345 civic and geospatial location information to be used. 347 * Regarding requirement 1.2, a number of fields in the civic 348 location information format are optional. 350 * Regarding requirement 1.3, the civic location information is 351 defined in an extensible way. 353 * Regarding requirement 1.4, the location information itself is 354 not defined in this document. 356 * Regarding requirement 1.5, the protocol described in this 357 document allows the Location Recipient to resolve a reference 358 to a PIDF-LO only. 360 * Regarding requirement 1.6, the Location Object contains both 361 location information and privacy rules. Depending on the 362 deployment scenario, which is outside the scope of this 363 document, the privacy rules might have stronger or a weaker 364 semantic. 366 * Regarding requirement 1.7, the Location Object is usable in a 367 variety of protocols. 369 * Regarding requirement 1.8, no change regarding with respect to 370 the encoding of the Location Object (see RFC 4119 [3]) was made 371 by this document. 373 Req. 2. (Location Object fields): 375 * Regarding requirement 2.1, depending on the deployment scenario 376 an identifier pointing to the Target may be carried inside the 377 PIDF-LO since the PIDF object provides the ability to carry 378 this identifier. In some circumstances it might be desirable 379 not to carry information about the Target's identity in the 380 PIDF-LO. 382 * Regarding requirement 2.2, depending on the deployment scenario 383 the Location Server might require that the Location Recipient 384 performs an authentication step. The security mechanisms for 385 client and server authentication are outside the scope of this 386 document and defined already for HTTPS itself. This document, 387 however, outlines how the authenticated identity is 388 instantiated for usage with the authorization policy framework. 390 * Regarding requirement 2.3, proof of possession of the Location 391 Recipient credentials is provided outside the scope of this 392 document. The security mechanisms defined for HTTPS are 393 utilized by this document. 395 * Regarding requirement 2.5, RFC 4119 defines the basis for 396 carrying location information in a PIDF document. The ability 397 to extend RFC 4119 to convey motion specific information is 398 work in progress. 400 * Regarding requirement 2.6, this document as specified only 401 allows the Location Recipient to resolve the reference but it 402 does not provide the capability to indicate which location 403 format or granularity has to be returned. 405 * Regarding requirement 2.7, the PIDF-LO relevant elements and 406 attributes are available. [[Editor's Note: I need to lookup 407 whether the PIDF-LO contains 'sighting time' and 'TTL']] 409 * Regarding requirement 2.8, a reference to an external (more 410 detailed rule set) is provided within the PIDF-LO. 412 * Regarding requirement 2.9, security headers and trailers are 413 provided Transport Layer Security. 415 * Regarding requirement 2.10, extensibility within the PIDF-LO is 416 provided regarding the definition of namespaces. 418 Req. 3. (Location Data Types): 420 * Regarding requirement 3.1, RFC 4119 [3] defines geospatial 421 location information as the mandatory to implement location 422 format. 424 * With the support of civic and geospatial location information 425 in RFC 4119 [3] the requirement 3.2 is fulfilled. 427 * Regarding requirement 3.3, the geospatial location information 428 used by this document only refers to absolute coordinates. 429 However, the granularity of the location information can be 430 reduced with the help of the AltRes, LoRes, LaRes fields 431 described in [7]. 433 * Regarding requirement 3.4, since the PIDF-LO format is designed 434 to be extensible it allows further location information to be 435 defined in the future. 437 Section 7.2 of [4] details the requirements of a "Using Protocol". 438 These requirements are listed below: 440 Req. 4.: The using protocol has to obey the privacy and security 441 instructions coded in the Location Object regarding the 442 transmission and storage of the LO. This document carries the 443 PIDF-LO as is via HTTPS from the Location Server to the Location 444 Recipient. The sending and receiving parties must obey the 445 instructions carried inside the object. 447 Req. 5.: The using protocol will typically facilitate that the keys 448 associated with the credentials are transported to the respective 449 parties, that is, key establishment is the responsibility of the 450 using protocol. This document does not define additional security 451 mechanisms beyond HTTPS. 453 Req. 6. (Single Message Transfer): In particular, for tracking of 454 small target devices, the design should allow a single message/ 455 packet transmission of location as a complete transaction. The 456 encoding of the RFC 4119-defined Location Object format is not 457 changed. Because of the verbose XML encoding it is not tailored 458 towards inclusion into a single message. 460 Section 7.3 of [4] details the requirements of a "Rule based Location 461 Data Transfer". These requirements are listed below: 463 Req. 7. (LS Rules): Depending on the deployment environment access 464 to location information might be controlled by authorization rules 465 created by the Rule Maker or by a short-lived reference that 466 contains a unguessable random component provided by the Target (or 467 by an entity on behalf of the Target). 469 Req. 8. (LG Rules): In context of Location-by-Reference it is not 470 possible that there is no relationship between the LG and the LS. 471 As such, the statement made in Req. 7 applies. 473 Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms 474 outside the scope of this document) which policy rules are 475 disclosed to other entities. These mechanisms are available with 476 [10]. 478 Req. 10. (Full Rule language): Geopriv has defined a rule language 479 capable of expressing a wide range of privacy rules which is 480 applicable in the area of the distribution of Location Objects. 481 The format of these rules are described in [5] and [10]. 483 Req. 11. (Limited Rule language): A limited (or basic) ruleset was 484 introduced with PIDF-LO [3]). 486 Section 7.4 of [4] details the requirements of a "Location Object 487 Privacy and Security". These requirements are listed below: 489 Req. 12 (Identity Protection): Identity protection of the Target can 490 be provided if (a) the protocol used to convey the reference does 491 not disclose the identity of the Target and (b) if the PIDF-LO 492 does not contain information about the identity about the Target. 493 Currently, there is no mechanism available that allows the Target 494 to tell the LS not to include identity information in the PIDF-LO. 496 Req. 13. (Credential Requirements): The security mechanism 497 specified in this document is Transport Layer Security. TLS 498 offers the ability to use different types of credentials, 499 including symmetric, asymmetric credentials or a combination of 500 them. 502 Req. 14. (Security Features): Geopriv defines a few security 503 requirements for the protection of Location Objects such as mutual 504 end-point authentication, data object integrity, data object 505 confidentiality and replay protection. The ability to use 506 Transport Layer security fulfills these requirements. 508 Req. 15. (Minimal Crypto): [[Editor's Note: A mandatory to 509 implement ciphersuite has to be specified in this document.]] 511 6. IANA Considerations 513 This document does not imply any actions for IANA. 515 7. Security Considerations 517 This document assumes that the use of TLS as substrate to HTTP is 518 sufficient to protect the privacy of the PIDF-LO content while in 519 flight. When access control has to be applied prior to conveying the 520 PIDF-LO towards the Location Recipient then the content of 521 Section 5.1 is applicable. The description about instantiating the 522 identity element allows the Common Policy authorization framework to 523 be used. In order to make reasonable authorization decisions the 524 Location Recipient needs to be authenticated (e.g., using HTTP Digest 525 Authentication or client-side TLS authentication) or to present 526 authorization information in the form of a SAML assertion. There is 527 ongoing work to update Digest Authentication, and those may 528 eventually require an update to the recommended authentication 529 method. If access control is not applied as described in the threat 530 models in Section 3 then the possession of the reference to location 531 information that must fulfill certain charactistics (such as 532 containing a random component) is sufficient to obtain be authorized 533 to resolve the reference to a PIDF-LO. 535 8. Acknowledgments 537 The authors would like to thank the GEOPRIV working group for 538 discussions in relationship to a Geopriv Layer 7 Location 539 Configuration Protocol and SIP Location Conveyance that motivate this 540 document. 542 The authors would like to thank Ted Hardie for the work with 543 draft-hardie-geopriv-https-strawman-00 document that served as a 544 basis for this document. 546 9. Open Issues 548 This document contains a couple of open issues and is primarily meant 549 to stimulate some discussions around dereferencing of HTTPS URIs to 550 PIDF-LOs. A further open issue is whether a GEOPRIV using protocol 551 should also define steps for publication of PIDF-LOs, as described 552 below. 554 9.1. Steps for publication 556 9.1.1. The client uses HTTPS to connect to the server 558 The client establishes an HTTPS connection to the server, as 559 described in RFC 2818. At the TLS layer, the use of 560 TLS_NULL_WITH_NULL_NULL MUST NOT be used as the CipherSuite. 562 9.1.2. The client authenticates to the server 564 The client authenticates to the server using HTTP's digest 565 authentication mechanism as described in RFC 2617 and updated by the 566 errata. 568 9.1.3. The client publishes the resource 570 The client publishes the PIDF-LO resource using an HTTP PUT request. 572 10. References 574 10.1. Normative References 576 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 577 Levels", BCP 14, RFC 2119, March 1997. 579 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 580 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 581 HTTP/1.1", RFC 2616, June 1999. 583 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 584 Format", RFC 4119, December 2005. 586 [4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 587 Polk, "Geopriv Requirements", RFC 3693, February 2004. 589 [5] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 590 J., and J. Rosenberg, "Common Policy: A Document Format for 591 Expressing Privacy Preferences", RFC 4745, February 2007. 593 [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 595 [7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 596 Configuration Protocol Option for Coordinate-based Location 597 Configuration Information", RFC 3825, July 2004. 599 [8] Duerst, M. and M. Suignard, "Internationalized Resource 600 Identifiers (IRIs)", RFC 3987, January 2005. 602 [9] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 603 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 604 Basic and Digest Access Authentication", RFC 2617, June 1999. 606 10.2. Informative References 608 [10] Schulzrinne, H., "Geolocation Policy: A Document Format for 609 Expressing Privacy Preferences for Location Information", 610 draft-ietf-geopriv-policy-12 (work in progress), May 2007. 612 [11] Barnes, M., "HTTP Enabled Location Delivery (HELD)", 613 draft-ietf-geopriv-http-location-delivery-00 (work in 614 progress), June 2007. 616 [12] Schulzrinne, H., "A Location Reference Event Package for the 617 Session Initiation Protocol (SIP)", 618 draft-schulzrinne-geopriv-locationref-00 (work in progress), 619 October 2006. 621 [13] Schulzrinne, H., "RELO: Retrieving End System Location 622 Information", draft-schulzrinne-geopriv-relo-03 (work in 623 progress), March 2007. 625 [14] Polk, J. and B. Rosen, "Session Initiation Protocol Location 626 Conveyance", draft-ietf-sip-location-conveyance-07 (work in 627 progress), February 2007. 629 [15] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 630 Configuration Protocol; Problem Statement and Requirements", 631 draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. 633 [16] Marshall, R., "Requirements for a Location-by-Reference 634 Mechanism used in Location Configuration and Conveyance", 635 draft-marshall-geopriv-lbyr-requirements-01 (work in progress), 636 March 2007. 638 Authors' Addresses 640 Hannes Tschofenig 641 Nokia Siemens Networks 642 Otto-Hahn-Ring 6 643 Munich, Bavaria 81739 644 Germany 646 Phone: +49 89 636 40390 647 Email: Hannes.Tschofenig@nsn.com 648 URI: http://www.tschofenig.com 650 Henning Schulzrinne 651 Columbia University 652 Department of Computer Science 653 450 Computer Science Building 654 New York, NY 10027 655 US 657 Phone: +1 212 939 7004 658 Email: hgs@cs.columbia.edu 659 URI: http://www.cs.columbia.edu 661 Full Copyright Statement 663 Copyright (C) The IETF Trust (2007). 665 This document is subject to the rights, licenses and restrictions 666 contained in BCP 78, and except as set forth therein, the authors 667 retain all their rights. 669 This document and the information contained herein are provided on an 670 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 671 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 672 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 673 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 674 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 675 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 677 Intellectual Property 679 The IETF takes no position regarding the validity or scope of any 680 Intellectual Property Rights or other rights that might be claimed to 681 pertain to the implementation or use of the technology described in 682 this document or the extent to which any license under such rights 683 might or might not be available; nor does it represent that it has 684 made any independent effort to identify any such rights. Information 685 on the procedures with respect to rights in RFC documents can be 686 found in BCP 78 and BCP 79. 688 Copies of IPR disclosures made to the IETF Secretariat and any 689 assurances of licenses to be made available, or the result of an 690 attempt made to obtain a general license or permission for the use of 691 such proprietary rights by implementers or users of this 692 specification can be obtained from the IETF on-line IPR repository at 693 http://www.ietf.org/ipr. 695 The IETF invites any interested party to bring to its attention any 696 copyrights, patents or patent applications, or other proprietary 697 rights that may cover technology that may be required to implement 698 this standard. Please address the information to the IETF at 699 ietf-ipr@ietf.org. 701 Acknowledgment 703 Funding for the RFC Editor function is provided by the IETF 704 Administrative Support Activity (IASA).