idnits 2.17.1
draft-ietf-geopriv-policy-uri-02.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 (October 4, 2011) is 4587 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-12
** 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-03
== Outdated reference: A later version (-27) exists of
draft-ietf-geopriv-policy-24
Summary: 3 errors (**), 0 flaws (~~), 4 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: April 6, 2012 J. Winterbottom
6 Andrew Corporation
7 H. Tschofenig
8 Nokia Siemens Networks
9 October 4, 2011
11 Location Configuration Extensions for Policy Management
12 draft-ietf-geopriv-policy-uri-02.txt
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 April 6, 2012.
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 . . . . . . . . . . . . . . . . . . . . . 5
62 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
63 4. Location Configuration Extensions . . . . . . . . . . . . . . 7
64 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
65 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
66 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8
67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
68 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
69 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
70 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10
71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
72 6.1. URN Sub-Namespace Registration for
73 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12
74 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
75 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
77 7.1. Integrity and Confidentiality for Authorization Policy
78 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
79 7.2. Access Control for Authorization Policy . . . . . . . . . 13
80 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
87 1. Introduction
89 A critical step in enabling Internet hosts to access location-based
90 services is to provision those hosts with information about their own
91 location. This is accomplished via a Location Configuration Protocol
92 (LCP) [RFC5687], which allows a location provider (e.g., a local
93 access network) to inform a host about its location.
95 There are two basic patterns for location configuration, namely
96 configuration "by value" and "by reference" [RFC5808]. Configuration
97 by value provisions a host directly with its location, by providing
98 it location information that is directly usable (e.g., coordinates or
99 a civic address). Configuration by reference provides a host with a
100 URI that references the host's location, i.e., one that can be
101 dereferenced to obtain the location (by value) of the host.
103 In some cases, location by reference offers a few benefits over
104 location by value. From a privacy perspective, the required
105 dereference transaction provides a policy enforcement point, so that
106 the opaque URI itself can be safely conveyed over untrusted media
107 (e.g., SIP through untrusted proxies [RFC5606]). If the target host
108 is mobile, an application provider can use a single reference to
109 obtain the location of the host multiple times, saving bandwidth to
110 the host. For some configuration protocols, the location object
111 referenced by a location URI provides a much more expressive syntax
112 for location values than the configuration protocol itself (e.g.,
113 DHCP geodetic location [RFC6225] versus GML in a PIDF-LO [RFC4119]).
115 From a privacy perspective, however, current LCPs are limited in
116 their flexibility, in that they do not provide hosts (the clients in
117 an LCP) with a way to inform the Location Server with policy for how
118 his location information should be handled. This document addresses
119 this gap by defining a simple mechanism for referring to and
120 manipulating policy, and by extending current LCPs to carry policy
121 references. Using the mechanisms defined in this document, an LCP
122 server (acting for the Location Server) can inform a host as to which
123 policy document controls a given location resource, and the host (in
124 its Rule Maker role) can inspect this document and modify it as
125 necessary.
127 In the following figure, adapted from RFC 5808, this document extends
128 the Location Configuration Protocols (1) and defines a simple
129 protocol for policy exchange (4).
131 +---------+---------+ Location +-----------+
132 | | | Dereference | Location |
133 | LIS/LS +---------------+ Recipient |
134 | | | Protocol | |
135 +----+----+----+----+ (3) +-----+-----+
136 | | |
137 | | |
138 Policy| |Location |Location
139 Exchange| |Configuration |Conveyance
140 (4)| |Protocol |Protocol
141 | |(1) |(2)
142 | | |
143 +------+----+----+----+ |
144 | Rule | Target/ | |
145 | Maker | Host +---------------------+
146 | | |
147 +-----------+---------+
149 The remainder of this document is structured as follows: After
150 introducing a few relevant terms, we define policy URIs as a channel
151 for referencing, inspecting, and updating policy documents. We then
152 define extensions to the HELD protocol and the DHCP option for
153 location by reference to allow these protocols to carry policy URIs.
154 Examples are given that demonstrate how policy URIs are carried in
155 these protocols and how they can be used by clients.
157 2. Definitions
159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
161 document are to be interpreted as described in RFC 2119 [RFC2119].
163 3. Policy URIs
165 A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that
166 identifies a policy resource that contains the authorization policy
167 for a linked location resource. Access to the location resource is
168 governed by the contents of the authorization policy.
170 A policy URI identifies an HTTP resource that a Rule Maker can use to
171 inspect and install policy documents that tell a Location Server how
172 it should protect the associated location resource. A policy URI
173 always identifies a resource that can be represented as a common-
174 policy document [RFC4745] (possibly including some extensions; e.g.,
175 for geolocation policy [I-D.ietf-geopriv-policy]).
177 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one
178 that stores policy information. In this document, the Location
179 Server is also a Rule Holder.
181 3.1. Policy URI Usage
183 A Location Server that is the authority for policy URIs MUST support
184 GET, PUT, and DELETE requests to these URIs, in order to allow
185 clients to inspect, replace, and delete policy documents. Clients
186 support the three request methods as they desire to perform these
187 operations.
189 Knowledge of the policy URI can be considered adequate evidence of
190 authorization. A Location Server SHOULD allow all requests, but it
191 MAY deny certain requests based on local policy. For instance, a
192 Location Server might allow clients to inspect policy (GET), but not
193 to update it (PUT).
195 A GET request to a policy URI is a request for the referenced policy
196 information. If the request is authorized, then the Location Server
197 sends an HTTP 200 response containing the complete policy identified
198 by the URI.
200 A PUT request to a policy URI is a request to replace the current
201 policy. The entity-body of a PUT request includes a complete policy
202 document. When a Location Server receives a PUT request, it MUST
203 validate the policy document included in the body of the request. If
204 the request is valid and authorized, then the Location Server MUST
205 replace the current policy with the policy provided in the request.
207 A DELETE request to a policy URI is a request to delete the
208 referenced policy document. If the request is authorized, then the
209 Location Server MUST delete the policy referenced by the URI and
210 disallow access to the location URIs it governs until a new policy
211 document has been put in place via a PUT request.
213 A policy URI is only valid while the corresponding location URI set
214 is valid. A location server MUST NOT respond to any requests to a
215 policy URIs once the corresponding location URI set has expired.
216 This expiry time is specified by the 'expires' attribute in the HELD
217 locationResponse or the 'Valid-For' LuriType in DHCP.
219 A location URI can thus become invalid in three ways: By the
220 expiration of a validity interval in policy, by the removal of a
221 policy document with a DELETE request, or by the expiry of the
222 LCP-specified validity interval. The former two are temporary,
223 since the policy URI can be used to update the policy. The latter
224 one is permanent, since the expiry causes the policy URI to be
225 invalidated as well.
227 The Location Server MUST support policy documents in the common-
228 policy format [RFC4745], as identified by the MIME media type of
229 "application/auth-policy+xml". The common-policy format MUST be
230 provided as the default format in response to GET requests that do
231 not include specific "Accept" headers, but content negotiation MAY be
232 used to allow for other formats.
234 This usage of HTTP is generally compatible with the use of XCAP
235 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this
236 document does not define or require the use of these protocols.
238 3.2. Policy URI Allocation
240 A Location Server creates a policy URI for a specific location
241 resource at the time that the location resource is created; that is,
242 a policy URI is created at the same time as the location URI that it
243 controls. The URI of the policy resource MUST be different from the
244 location URI.
246 A policy URI is provided in response to location configuration
247 requests. A policy URI MUST NOT be provided to an entity that is not
248 authorized to view or set policy. This document does not describe
249 how policy might be provided to entities other than for location
250 configuration, for example, in responses to dereferencing requests
251 [I-D.ietf-geopriv-deref-protocol] or requests from third parties
252 [RFC6155].
254 Each location URI has either one policy URI or no policy URI. The
255 initial policy that is referenced by a policy URI MUST be identical
256 to the policy that would be applied in the absence of a policy URI.
257 A client that does not support policy URIs can continue to use the
258 location URI as they would have if no policy URI were provided.
260 For DHCP and HELD, the client assumes that the default policy
261 grants any requester access to location information, as long as
262 the request possesses the location URI. To ensure that the
263 authorization policy is less permissive, a client updates the
264 policy prior to distributing the location URI.
266 A Location Server chooses whether or not to provide a policy URI
267 based on local policy. A HELD-specific extension also allows a
268 requester to specifically ask for a policy URI.
270 A policy URI is effectively a shared secret between Location Server
271 and its clients. Knowledge of a policy URI is all that is required
272 to perform any operations allowed on the policy. Thus, a policy URI
273 should be constructed so that it is hard to predict and
274 confidentiality-protected when transmitted (see Section 7). To avoid
275 re-using these shared secrets, the Location Server MUST generate a
276 new policy URI whenever it generates a new location URI set.
278 4. Location Configuration Extensions
280 Location configuration protocols can provision hosts with location
281 URIs that refer to the host's location. If the target host is to
282 control policy on these URIs, it needs a way to access the policy
283 that the Location Server uses to guide how it serves location URIs.
284 This section defines extensions to LCPs to carry policy URIs that the
285 target can use to control access to location resources.
287 4.1. HELD
289 The HELD protocol [RFC5985] defines a "locationUriSet" element, which
290 contain a set of one or more location URIs that reference the same
291 resource and share a common access control policy. The schema in
292 Figure 1 defines two extension elements for HELD: an empty
293 "requestPolicyUri" element that is added to a location request to
294 indicate that a Device desires that a policy URI be allocated; and a
295 "policyUri" element that is included in the location response.
297
298
304
305
306
308
310
312 Figure 1
314 The URI carried in a "policyUri" element refers to the common access
315 control policy for location URIs in the location response. The URI
316 MUST be a policy URI as described in Section 3. A policy URI MUST
317 use the "http:" or "https:" scheme, and the Location Server MUST
318 support the specified operations on the URI.
320 A HELD request MAY contain an explicit request for a policy URI. The
321 presence of the "requestPolicyUri" element in a location request
322 indicates that a policy URI is desired.
324 4.2. DHCP
326 The DHCP location by reference option
327 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in
328 sub-options called LuriElements. This document defines a new
329 LuriElement type for policy URIs.
331 LuriType=TBD Policy-URI - This is a policy URI that refers to the
332 access control policy for the location URIs.
334 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
335 LuriType value and remove this note]
337 A Policy-URI LuriElement uses a UTF-8 character encoding.
339 A Policy-URI LuriElement identifies the policy resource for all
340 location URIs included in the location URI option. The URI MUST be a
341 policy URI as described in Section 3: It MUST use either the "http:"
342 or "https:" scheme, and the Location Server MUST support the
343 specified operations on the URI.
345 4.3. Client Processing
347 It is possible that this document will be updated to allow the use of
348 policy URIs that use protocols other than the HTTP-based protocol
349 described above. To ensure that they fail safely when presented with
350 such a URI, clients implementing this specification MUST verify that
351 a policy URI received from either HELD or DHCP uses either the
352 "http:" or "https:" scheme. If the URI does not match those schemes,
353 then the client MUST discard the URI and behave as if no policy URI
354 was provided.
356 5. Examples
358 In this section, we provide some brief illustrations of how policy
359 URIs are delivered to target hosts and used by those hosts to manage
360 policy.
362 5.1. HELD
364 A HELD request that explicitly requests the creation of a policy URI
365 has the following form:
367
368 locationURI
369
371
373 A HELD response providing a single "locationUriSet", containing two
374 URIs under a common policy, would have the following form:
376
377
378
379 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
380
381
382 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
383
384
385
386 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
387
388
390 5.2. DHCP
392 A DHCP option providing one of the location URIs and the
393 corresponding policy URI from the previous example would have the
394 following form:
396 0 1 2 3
397 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
398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
399 | option-code | 110 |
400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401 | 1 | 0 | 1 | 49 | 'h' |
402 +---------------+---------------+---------------+---------------|
403 | 't' | 't' | 'p' | 's' |
404 +---------------+---------------+---------------+---------------|
405 | ':' | '/' | '/' | 'l' |
406 +---------------+---------------+---------------+---------------|
407 | 's' | '.' | ... |
408 +---------------+---------------+---------------+---------------|
409 | TBD | 56 | 'h' 't' |
410 +---------------+---------------+---------------+---------------|
411 | 't' | 'p' | 's' | ':' |
412 +---------------+---------------+---------------+---------------|
413 | '/' | '/' | ... |
414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
416 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
417 LuriType value and remove this note]
419 5.3. Basic Access Control Policy
421 Consider a client that gets the policy URI
422 , as in the
423 above LCP example. The first thing this allows the client to do is
424 inspect the default policy that the LS has assigned to this URI:
426 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
427 Host: ls.example.com:9768
429 HTTP/1.1 200 OK
430 Content-type: application/auth-policy+xml
431 Content-length: 388
433
434
436
437
438
439 2011-01-01T13:00:00.0Z
440
441
442
443
444
445
446 false
447
448 0
449
450
451
453 This policy allows any requester to obtain location information, as
454 long as they know the location URI. If the user disagrees with this
455 policy, and prefers for example, to only provide location to one
456 friend, at a city level of granularity, then the client can install
457 this policy on the Location Server:
459 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
460 Host: ls.example.com:9768
461 Content-type: application/auth-policy+xml
462 Content-length: 462
464
465
466
467
468
469
470
471
472 2011-01-01T13:00:00.0Z
473
474
475
476
477
479 city
480
481
482
483
485 HTTP/1.1 200 OK
487 Finally, after using the URI for a period, the user wishes to
488 permanently invalidate the URI.
490 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
491 Host: ls.example.com:9768
493 HTTP/1.1 200 OK
495 6. IANA Considerations
497 This document requires several IANA registrations, detailed below.
499 6.1. URN Sub-Namespace Registration for
500 urn:ietf:params:xml:ns:geopriv:held:policy
502 This section registers a new XML namespace,
503 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in
504 [RFC3688].
506 URI: urn:ietf:params:xml:ns:geopriv:held:policy
508 Registrant Contact: IETF, GEOPRIV working group,
509 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).
511 XML:
513 BEGIN
514
515
517
518
519 HELD Policy URI Extension
520
521
522 Namespace for HELD Policy URI Extension
523 urn:ietf:params:xml:ns:geopriv:held:policy
524 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
525 with the RFC number for this specification.]
526 See RFCXXXX
527
528
529 END
531 6.2. XML Schema Registration
533 This section registers an XML schema as per the guidelines in
534 [RFC3688].
536 URI: urn:ietf:params:xml:schema:geopriv:held:policy
538 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
539 Richard Barnes (rbarnes@bbn.com)
541 Schema: The XML for this schema can be found in Section Section 4.1.
543 6.3. DHCP LuriType Registration
545 IANA is requested to add a value to the LuriTypes registry, as
546 follows:
548 +------------+----------------------------------------+-----------+
549 | LuriType | Name | Reference |
550 +------------+----------------------------------------+-----------+
551 | TBD* | Policy-URI | RFC XXXX**|
552 +------------+----------------------------------------+-----------+
554 * TBD is to be replaced with the assigned value
555 ** RFC XXXX is to be replaced with this document's RFC number.
557 7. Security Considerations
559 There are two main classes of risks associated with access control
560 policy management: The risk of unauthorized disclosure of the
561 protected resource via manipulation of the policy management process,
562 and the risk of disclosure of policy information itself.
564 Protecting the policy management process from manipulation entails
565 two primary requirements: First, the policy URI has to be faithfully
566 and confidentially transmitted to the client, and second, the policy
567 document has to be faithfully and confidentially transmitted to the
568 Location Server. The mechanism also needs to ensure that only
569 authorized entities are able to acquire or alter policy.
571 7.1. Integrity and Confidentiality for Authorization Policy Data
573 Each LCP ensures integrity and confidentiality through different
574 means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
575 These measures ensure that a policy URI is conveyed to the client
576 without modification or interception.
578 To protect the integrity and confidentiality of policy data during
579 management, the Location Server SHOULD provide policy URIs with the
580 "https:" scheme and require the use of HTTP over TLS [RFC2818]. The
581 cipher suites required by TLS [RFC5246] provide both integrity
582 protection and confidentiality. If other means of protection are
583 available, an "http:" URI MAY be used.
585 7.2. Access Control for Authorization Policy
587 Access control for the policy resource is based on knowledge of its
588 URI. The URI of a policy resource operates under the same
589 constraints as a possession model location URI [RFC5808] and is
590 subject to the same constraints:
592 o Knowledge of a policy URI MUST be restricted to authorized Rule
593 Makers. Confidentiality is required for its conveyance in the
594 location configuration protocol, and in the requests that are used
595 to inspect, change or delete the policy resource.
597 o The Location Server MUST ensure that the URI cannot be easily
598 predicted. The policy URI MUST NOT be derived solely from
599 information that might be public, including the Target identity or
600 any location URI. The addition of random entropy increases the
601 difficulty of guessing a policy URI.
603 7.3. Location URI Allocation
605 A policy URI enables the authorization by access control lists model
606 [RFC5808] for associated location URIs. Under this model, it might
607 be possible to more widely distribute a location URI, relying on the
608 authorization policy to constrain access to location information.
610 To allow for wider distribution, authorization by access control
611 lists places additional constraints on the construction of location
612 URIs.
614 If multiple Targets share a location URI, an unauthorized location
615 recipient that acquires location URIs for the Targets can determine
616 that the Targets are at the same location by comparing location URIs.
617 With shared policy URIs, Targets are able to see and modify
618 authorization policy for other Targets.
620 To allow for the creation of Target-specific authorization policies
621 that are adequately privacy-protected, each location URI and policy
622 URI that is issued to a different Target MUST be different from other
623 location URIs and policy URIs. That is, two clients MUST NOT receive
624 the same location URI or the same policy URI.
626 In some deployments, it is not always apparent to a LCP server that
627 two clients are different. In particular, where a middlebox
628 [RFC3234] exists two or more clients might appear as a single client.
629 An example of a deployment scenario of this nature is described in
630 [RFC5687]. An LCP server MUST create a different location URI and
631 policy URI for every request, unless the requests can be reliably
632 identified as being from the same client.
634 8. Acknowledgements
636 Thanks to Mary Barnes and Alissa Cooper for providing critical
637 commentary and input on the ideas described in this document, and to
638 Ted Hardie and Adam Roach for helping clarify the relationships
639 between policy URIs, policy documents, and location resources.
641 9. References
643 9.1. Normative References
645 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
646 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
647 and IPv6 Option for a Location Uniform Resource Identifier
648 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work
649 in progress), October 2011.
651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
652 Requirement Levels", BCP 14, RFC 2119, March 1997.
654 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
655 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
656 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
658 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
660 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
661 January 2004.
663 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
664 Polk, J., and J. Rosenberg, "Common Policy: A Document
665 Format for Expressing Privacy Preferences", RFC 4745,
666 February 2007.
668 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
669 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
671 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
672 RFC 5985, September 2010.
674 9.2. Informative References
676 [I-D.ietf-geopriv-deref-protocol]
677 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
678 Thomson, M., and M. Dawson, "A Location Dereferencing
679 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-03
680 (work in progress), June 2011.
682 [I-D.ietf-geopriv-policy]
683 Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
684 and J. Morris, "Geolocation Policy: A Document Format for
685 Expressing Privacy Preferences for Location Information",
686 draft-ietf-geopriv-policy-24 (work in progress),
687 September 2011.
689 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
690 Issues", RFC 3234, February 2002.
692 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
693 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
695 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
696 Format", RFC 4119, December 2005.
698 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
699 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
701 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
702 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
704 [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of
705 'retransmission-allowed' for SIP Location Conveyance",
706 RFC 5606, August 2009.
708 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
709 Location Configuration Protocol: Problem Statement and
710 Requirements", RFC 5687, March 2010.
712 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
713 Mechanism", RFC 5808, May 2010.
715 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
716 Barnes, "Use of Device Identity in HTTP-Enabled Location
717 Delivery (HELD)", RFC 6155, March 2011.
719 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
720 Host Configuration Protocol Options for Coordinate-Based
721 Location Configuration Information", RFC 6225, July 2011.
723 Authors' Addresses
725 Richard Barnes
726 BBN Technologies
727 9861 Broken Land Parkway
728 Columbia, MD 21046
729 US
731 Phone: +1 410 290 6169
732 Email: rbarnes@bbn.com
734 Martin Thomson
735 Andrew Corporation
736 Andrew Building (39)
737 Wollongong University Campus
738 Northfields Avenue
739 Wollongong, NSW 2522
740 AU
742 Phone: +61 2 4221 2915
743 Email: martin.thomson@andrew.com
745 James Winterbottom
746 Andrew Corporation
747 Andrew Building (39)
748 Wollongong University Campus
749 Northfields Avenue
750 Wollongong, NSW 2522
751 AU
753 Phone: +61 242 212938
754 Email: james.winterbottom@andrew.com
756 Hannes Tschofenig
757 Nokia Siemens Networks
758 Linnoitustie 6
759 Espoo 02600
760 Finland
762 Phone: +358 (50) 4871445
763 Email: Hannes.Tschofenig@gmx.net
764 URI: http://www.tschofenig.priv.at