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