idnits 2.17.1 draft-ietf-geopriv-policy-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (January 12, 2011) is 4846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-09 ** 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-02 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-22 == Outdated reference: A later version (-17) exists of draft-ietf-geopriv-rfc3825bis-14 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational M. Thomson 5 Expires: July 16, 2011 J. Winterbottom 6 Andrew Corporation 7 H. Tschofenig 8 Nokia Siemens Networks 9 January 12, 2011 11 Location Configuration Extensions for Policy Management 12 draft-ietf-geopriv-policy-uri-00 14 Abstract 16 Current location configuration protocols are capable of provisioning 17 an Internet host with a location URI that refers to the host's 18 location. These protocols lack a mechanism for the target host to 19 inspect or set the privacy rules that are applied to the URIs they 20 distribute. This document extends the current location configuration 21 protocols to provide hosts with a reference to the rules that are 22 applied to a URI, so that the host can view or set these rules. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 16, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 5 63 4. Location Configuration Extensions . . . . . . . . . . . . . . 6 64 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.3. Basic access control policy . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7.1. URN Sub-Namespace Registration for 73 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 11 74 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 75 7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8.1. Integrity and Confidentiality for Authorization Policy 78 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.2. Access Control for Authorization Policy . . . . . . . . . 13 80 8.3. Location URI Allocation . . . . . . . . . . . . . . . . . 13 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 A critical step in enabling Internet hosts to access location-based 89 services is to provision those hosts with information about their own 90 location. This is accomplished via a Location Configuration Protocol 91 (LCP) [RFC5687], which allows a location provider (e.g., a local 92 access network) to inform a host about its location. 94 There are two basic patterns for location configuration, namely 95 configuration "by value" and "by reference" [RFC5808]. Configuration 96 by value provisions a host directly with its location, by providing 97 it location information that is directly usable (e.g., coordinates or 98 a civic address). Configuration by reference provides a host with a 99 URI that references the host's location, i.e., one that can be 100 dereferenced to obtain the location (by value) of the host. 102 In some cases, location by reference offers a few benefits over 103 location by value. From a privacy perspective, the required 104 dereference transaction provides a policy enforcement point, so that 105 the opaque URI itself can be safely conveyed over untrusted media 106 (e.g., SIP through untrusted proxies [RFC5606]). If the target host 107 is mobile, an application provider can use a single reference to 108 obtain the location of the host multiple times, saving bandwidth to 109 the host. For some configuration protocols, the location object 110 referenced by a location URI provides a much more expressive syntax 111 for location values than the configuration protocol itself (e.g., 112 DHCP geodetic location [I-D.ietf-geopriv-rfc3825bis] versus GML in a 113 PIDF-LO [RFC4119]). 115 From a privacy perspective, however, current LCPs are limited in 116 their flexibility, in that they do not provide the Device (the client 117 in an LCP) with a way to inform the Location Server with policy for 118 how his location information should be handled. This document 119 addresses this gap by defining a simple mechanism for referring to 120 and manipulating policy, and by extending current LCPs to carry 121 policy references. Using the mechanisms defined in this document, an 122 LCP server (acting for the Location Server) can inform a client as to 123 which policy document controls a given location resource, and the LCP 124 client (in its Rule Maker role) can inspect this document and modify 125 it as necessary. 127 The remainder of this document is structured as follows: After 128 introducing a few relevant terms, we define policy URIs as a channel 129 for referencing, inspecting, and updating policy documents. We then 130 define extensions to the HELD protocol and the DHCP option for 131 location by reference to allow these protocols to carry policy URIs. 132 Examples are given that demonstrate how policy URIs are carried in 133 these protocols and how they can be used by clients. 135 2. Definitions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Policy URIs 143 A policy URI is an HTTP [RFC2616] URI that identifies a policy 144 resource that contains the authorization policy for a linked location 145 resource. Access to the location resource is governed by the 146 contents of the authorization policy. 148 A policy URI identifies an HTTP resource that a Rule Maker can use to 149 inspect and install policy documents that tell a Location Server how 150 it should protect the associated location resource. A policy URI 151 always identifies a resource that can be represented as a common- 152 policy document [RFC4745] (possibly including some extensions; e.g., 153 for geolocation policy [I-D.ietf-geopriv-policy]). 155 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one 156 that stores policy information. In this document, the Location 157 Server is also a Rule Holder. 159 3.1. Policy URI Usage 161 A Location Server that is the authority for policy URIs MUST support 162 GET, PUT, and DELETE requests to these URIs, in order to allow 163 clients to inspect, replace, and delete policy documents. Clients 164 support the three request methods as they desire to perform these 165 operations. 167 Knowledge of the policy URI can be considered adequate evidence of 168 authorization. A Location Server SHOULD allow all requests, but it 169 MAY deny certain requests based on local policy. For instance, a 170 Location Server might allow clients to inspect policy (GET), but not 171 to update it (PUT). 173 A GET request to a policy URI is a request for the referenced policy 174 information. If the request is authorized, then the Location Server 175 sends an HTTP 200 response containing the complete policy identified 176 by the URI. 178 A PUT request to a policy URI is a request to replace the current 179 policy. The entity-body of a PUT request includes a complete policy 180 document. When a Location Server receives a PUT request, it MUST 181 validate the policy document included in the body of the request. If 182 the request is valid and authorized, then the Location Server 183 replaces the current policy with the policy provided in the request. 185 A DELETE request to a policy URI is a request to delete the 186 referenced policy document and terminate access to the protected 187 resource. If the request is authorized, then the Location Server 188 deletes the policy referenced by the URI and disallows any further 189 access to the location resource it governs. 191 The Location Server MUST support policy documents in the common- 192 policy format [RFC4745], as identified by the MIME media type of 193 "application/auth-policy+xml". The common-policy format MUST be 194 provided as the default format in response to GET requests that do 195 not include specific "Accept" headers, but content negotiation MAY be 196 used to allow for other formats. 198 This usage of HTTP is generally compatible with the use of XCAP 199 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this 200 document does not define or require the use of these protocols. 202 3.2. Policy URI Allocation 204 A Location Server creates a policy URI for a specific location 205 resource at the time that the location resource is created; that is, 206 a policy URI is created at the same time as the location URI that it 207 controls. The URI of the policy resource MUST be different to the 208 location URI. 210 A policy URI is provided in response to location configuration 211 requests. A policy URI MUST NOT be provided to an entity that is not 212 authorized to view or set policy. This document does not describe 213 how policy might be provided to entities other than for location 214 configuration. in responses to dereferencing requests 215 [I-D.ietf-geopriv-deref-protocol] or requests from third parties 216 [I-D.ietf-geopriv-held-identity-extensions]. 218 Each location URI has either one policy URI or no policy URI. The 219 initial policy that is referenced by a policy URI MUST be identical 220 to the policy that would be applied in the absence of a policy URI. 221 A client that does not support policy URIs can continue to use the 222 location URI as they would have if no policy URI were provided. 224 For DHCP and HELD, the client assumes that the default policy 225 grants any requester access to location information, as long as 226 the request possesses the location URI. To ensure that the 227 authorization policy is less permissive, a client updates the 228 policy prior to distributing the location URI. 230 A Location Server chooses whether or not to provide a policy URI 231 based on local policy. A HELD-specific extension also allows a 232 requester to specifically ask for a policy URI. 234 A policy URI is a shared secret between Location Server and its 235 clients. Knowledge of a policy URI is all that is required to 236 perform any operations allowed on the policy. Thus, a policy URI is 237 constructed so that it is hard to predict (see Section 8). 239 4. Location Configuration Extensions 241 Location configuration protocols can provision hosts with location 242 URIs that refer to the host's location. If the target host is to 243 control policy on these URIs, it needs a way to access the policy 244 that the Location Server uses to guide how it serves location URIs. 245 This section defines extensions to LCPs to carry policy URIs that the 246 target can use to control access to location resources. 248 4.1. HELD 250 The HELD protocol [RFC5985] defines a "locationUriSet" element, which 251 contain a set of one or more location URIs that reference the same 252 resource and share a common access control policy. The schema in 253 Figure 1 defines two extension elements for HELD: an empty 254 "requestPolicyUri" element that is added to a location request to 255 indicate that a Device desires that a policy URI be allocated; and a 256 "policyUri" element that is included in the location response. 258 259 265 266 267 269 271 273 Figure 1 275 The URI carried in a "policyUri" element refers to the common access 276 control policy for location URIs in the location response. The URI 277 MUST be a policy URI as described in Section 3. A policy URI MUST 278 use the "http:" or "http:" scheme, and the Location Server MUST 279 support the specified operations on the URI. 281 A HELD request MAY contain an explicit request for a policy URI. The 282 presence of the "requestPolicyUri" element in a location request 283 indicates that a policy URI is desired. 285 4.2. DHCP 287 The DHCP location by reference option 288 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in 289 sub-options called LuriElements. This document defines a new 290 LuriElement type for policy URIs. 292 LuriType=TBD Policy-URI - This is a policy URI that refers to the 293 access control policy for the location URIs. 295 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 296 LuriType value and remove this note] 298 A Policy-URI LuriElement uses a UTF-8 character encoding. 300 A Policy-URI LuriElement identifies the policy resource for all 301 location URIs included in the location URI option. The URI MUST be a 302 policy URI as described in Section 3: It MUST use either the "http:" 303 or "https:" scheme, and the Location Server MUST support the 304 specified operations on the URI. 306 5. Examples 308 In this section, we provide some brief illustrations of how policy 309 URIs are delivered to target hosts and used by those hosts to manage 310 policy. 312 5.1. HELD 314 A HELD request that explicitly requests the creation of a policy URI 315 has the following form: 317 318 locationURI 319 321 323 A HELD response providing a single "locationUriSet", containing two 324 URIs under a common policy, would have the following form: 326 327 328 329 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 330 331 332 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 333 334 335 336 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b 337 338 340 5.2. DHCP 342 A DHCP option providing one of the location URIs and the 343 corresponding policy URI from the previous example would have the 344 following form: 346 0 1 2 3 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | option-code | 110 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | 1 | 0 | 1 | 49 | 'h' | 352 +---------------+---------------+---------------+---------------| 353 | 't' | 't' | 'p' | 's' | 354 +---------------+---------------+---------------+---------------| 355 | ':' | '/' | '/' | 'l' | 356 +---------------+---------------+---------------+---------------| 357 | 's' | '.' | ... | 358 +---------------+---------------+---------------+---------------| 359 | TBD | 56 | 'h' 't' | 360 +---------------+---------------+---------------+---------------| 361 | 't' | 'p' | 's' | ':' | 362 +---------------+---------------+---------------+---------------| 363 | '/' | '/' | ... | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 367 LuriType value and remove this note] 369 5.3. Basic access control policy 371 Consider a user that gets the policy URI 372 , as in the 373 above LCP example. The first thing this allows the user to do is 374 inspect the default policy that the LS has assigned to this URI: 376 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 377 Host: ls.example.com:9768 379 HTTP/1.1 200 OK 380 Content-type: application/auth-policy+xml 381 Content-length: 388 383 384 386 387 388 389 2011-01-01T13:00:00.0Z 390 391 392 393 394 395 396 false 397 398 0 399 400 401 403 This policy allows any requester to obtain location information, as 404 long as they know the location URI. If the user disagrees with this 405 policy, and prefers for example, to only provide location to one 406 friend, at a city level of granularity, then he can install this 407 policy on the Location Server: 409 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 410 Host: ls.example.com:9768 411 Content-type: application/auth-policy+xml 412 Content-length: 462 414 415 416 417 418 419 420 421 422 2011-01-01T13:00:00.0Z 423 424 425 426 427 429 city 430 431 432 433 435 HTTP/1.1 200 OK 437 Finally, after using the URI for a period, the user wishes to 438 permanently invalidate the URI. 440 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 441 Host: ls.example.com:9768 443 HTTP/1.1 200 OK 445 6. Acknowledgements 447 Thanks to Mary Barnes, Alissa Cooper, and Hannes Tschofenig for 448 providing critical commentary and input on the ideas described in 449 this document. 451 7. IANA Considerations 453 This document requires several IANA registrations, detailed below. 455 7.1. URN Sub-Namespace Registration for 456 urn:ietf:params:xml:ns:geopriv:held:policy 458 This section registers a new XML namespace, 459 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in 460 [RFC3688]. 462 URI: urn:ietf:params:xml:ns:grip 464 Registrant Contact: IETF, GEOPRIV working group, 465 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). 467 XML: 469 BEGIN 470 471 473 474 475 HELD Policy URI Extension 476 477 478

Namespace for HELD Policy URI Extension

479

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

480 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 481 with the RFC number for this specification.] 482

See RFCXXXX

483 484 485 END 487 7.2. XML Schema Registration 489 This section registers an XML schema as per the guidelines in 490 [RFC3688]. 492 URI: urn:ietf:params:xml:schema:geopriv:held:policy 494 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 495 Richard Barnes (rbarnes@bbn.com) 497 Schema: The XML for this schema can be found in Section Section 4.1. 499 7.3. DHCP LuriType Registration 501 IANA is requested to add a value to the LuriTypes registry, as 502 follows: 504 +------------+----------------------------------------+-----------+ 505 | LuriType | Name | Reference | 506 +------------+----------------------------------------+-----------+ 507 | TBD* | Policy-URI | RFC XXXX**| 508 +------------+----------------------------------------+-----------+ 510 * TBD is to be replaced with the assigned value 511 ** RFC XXXX is to be replaced with this document's RFC number. 513 8. Security Considerations 515 There are two main classes of risks associated with access control 516 policy management: The risk of unauthorized disclosure of the 517 protected resource via manipulation of the policy management process, 518 and the risk of disclosure of policy information itself. 520 Protecting the policy management process from manipulation entails 521 two primary requirements: First, the policy URI has to be faithfully 522 and confidentially transmitted to the client, and second, the policy 523 document has to be faithfully and confidentially transmitted to the 524 Location Server. The mechanism also needs to ensure that only 525 authorized entities are able to acquire or alter policy. 527 8.1. Integrity and Confidentiality for Authorization Policy Data 529 Each LCP ensures integrity and confidentiality through different 530 means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). 531 These measures ensure that a policy URI is conveyed to the client 532 without modification or interception. 534 To protect the integrity and confidentiality of policy data during 535 management, the Location Server SHOULD provide policy URIs with the 536 "https:" scheme and require the use of HTTP over TLS [RFC2818]. The 537 cipher suites required by TLS [RFC5246] provide both integrity 538 protection and confidentiality. If other means of protection are 539 available, an "http:" URI MAY be used. 541 8.2. Access Control for Authorization Policy 543 Access control for the policy resource is based on knowledge of its 544 URI. The URI of a policy resource operates under the same 545 constraints as a possession model location URI [RFC5808] and is 546 subject to the same constraints: 548 o Knowledge of a policy URI MUST be restricted to authorized Rule 549 Makers. Confidentiality is required for its conveyance in the 550 location configuration protocol, and in the requests that are used 551 to inspect, change or delete the policy resource. 553 o The Location Server MUST ensure that the URI cannot be easily 554 predicted. The policy URI MUST NOT be derived solely from 555 information that might be public, including the Target identity or 556 any location URI. The addition of random entropy increases the 557 difficulty of guessing a policy URI. 559 8.3. Location URI Allocation 561 A policy URI enables the authorization by access control lists model 562 [RFC5808] for associated location URIs. Under this model, it might 563 be possible to more widely distribute a location URI, relying on the 564 authorization policy to constrain access to location information. 566 To allow for wider distribution, authorization by access control 567 lists places additional constraints on the construction of location 568 URIs. 570 If multiple Targets share a location URI, an unauthorized location 571 recipient that acquires location URIs for the Targets can determine 572 that the Targets are at the same location by comparing location URIs. 573 With shared policy URIs, Targets are able to see and modify 574 authorization policy for other Targets. 576 To allow for the creation of Target-specific authorization policies 577 that are adequately privacy-protected, every location URI and policy 578 URI that is issued to a different Target MUST be different. That is, 579 no two client can receive the same location URI or policy URI. 581 In some deployments it is not always apparent to a LCP server that 582 two clients are different. In particular, where a middlebox 583 [RFC3234] exists two or more clients might appear as a single client. 584 An example of a deployment scenario of this nature is described in 585 [RFC5687]. An LCP server MUST create a different location URI and 586 policy URI for every request, unless the requests can be reliably 587 identified as being from the same client. 589 9. References 591 9.1. Normative References 593 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 594 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 595 and IPv6 Option for a Location Uniform Resource Identifier 596 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-09 (work 597 in progress), October 2010. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 603 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 604 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 606 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 608 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 609 January 2004. 611 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 612 Polk, J., and J. Rosenberg, "Common Policy: A Document 613 Format for Expressing Privacy Preferences", RFC 4745, 614 February 2007. 616 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 617 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 619 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 620 RFC 5985, September 2010. 622 9.2. Informative References 624 [I-D.ietf-geopriv-deref-protocol] 625 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 626 Thomson, M., and M. Dawson, "A Location Dereferencing 627 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 628 (work in progress), December 2010. 630 [I-D.ietf-geopriv-held-identity-extensions] 631 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 632 Barnes, "Use of Device Identity in HTTP-Enabled Location 633 Delivery (HELD)", 634 draft-ietf-geopriv-held-identity-extensions-06 (work in 635 progress), November 2010. 637 [I-D.ietf-geopriv-policy] 638 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 639 and J. Polk, "Geolocation Policy: A Document Format for 640 Expressing Privacy Preferences for Location Information", 641 draft-ietf-geopriv-policy-22 (work in progress), 642 October 2010. 644 [I-D.ietf-geopriv-rfc3825bis] 645 Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B. 646 Aboba, "Dynamic Host Configuration Protocol Options for 647 Coordinate-based Location Configuration Information", 648 draft-ietf-geopriv-rfc3825bis-14 (work in progress), 649 November 2010. 651 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 652 Issues", RFC 3234, February 2002. 654 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 655 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 657 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 658 Format", RFC 4119, December 2005. 660 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 661 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 663 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 664 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 666 [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 667 'retransmission-allowed' for SIP Location Conveyance", 668 RFC 5606, August 2009. 670 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 671 Location Configuration Protocol: Problem Statement and 672 Requirements", RFC 5687, March 2010. 674 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 675 Mechanism", RFC 5808, May 2010. 677 Authors' Addresses 679 Richard Barnes 680 BBN Technologies 681 9861 Broken Land Parkway 682 Columbia, MD 21046 683 US 685 Phone: +1 410 290 6169 686 Email: rbarnes@bbn.com 688 Martin Thomson 689 Andrew Corporation 690 Andrew Building (39) 691 Wollongong University Campus 692 Northfields Avenue 693 Wollongong, NSW 2522 694 AU 696 Phone: +61 2 4221 2915 697 Email: martin.thomson@andrew.com 699 James Winterbottom 700 Andrew Corporation 701 Andrew Building (39) 702 Wollongong University Campus 703 Northfields Avenue 704 Wollongong, NSW 2522 705 AU 707 Phone: +61 242 212938 708 Email: james.winterbottom@andrew.com 710 Hannes Tschofenig 711 Nokia Siemens Networks 712 Linnoitustie 6 713 Espoo 02600 714 Finland 716 Phone: +358 (50) 4871445 717 Email: Hannes.Tschofenig@gmx.net 718 URI: http://www.tschofenig.priv.at