draft-ietf-geopriv-deref-protocol-00.txt   draft-ietf-geopriv-deref-protocol-01.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Andrew Corporation Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: January 6, 2011 Nokia Siemens Networks Expires: April 2, 2011 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson M. Dawson
Andrew Corporation Andrew Corporation
July 5, 2010 September 29, 2010
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-00 draft-ietf-geopriv-deref-protocol-01
Abstract Abstract
This document describes how to use the Hypertext Transfer Protocol This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing (HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a secure HELD URI that can be used in conjunction Recipient possesses a secure HELD URI that can be used in conjunction
with the HELD protocol to request the location of the Target. with the HELD protocol to request the location of the Target.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2011. This Internet-Draft will expire on April 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6
3.2. Authorization via Access Control . . . . . . . . . . . . . 7 3.2. Authorization via Access Control . . . . . . . . . . . . . 7
3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 3.3. Access Control with HELD Deference . . . . . . . . . . . . 7
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8
4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative references . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 15 9.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix B. Compliance to Location Reference Requirements . . . . 18 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
B.1. Requirements for a Location Configuration Protocol . . . . 18 Appendix B. Compliance to Location Reference Requirements . . . . 19
B.2. Requirements for a Location Dereference Protocol . . . . . 20 B.1. Requirements for a Location Configuration Protocol . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 B.2. Requirements for a Location Dereference Protocol . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Provision of location information by reference [RFC5808] involves the Provision of location information by reference [RFC5808] involves the
creation of a resource that is identified by a "location URI". A creation of a resource that is identified by a "location URI". A
"location URI" identifies resource that contains the location of an "location URI" identifies resource that contains the location of an
entity. A location URI might be a temporary resource, created in entity. A location URI might be a temporary resource, created in
response to a HTTP-Enabled Location Delivery (HELD) response to a HTTP-Enabled Location Delivery (HELD)
[I-D.ietf-geopriv-http-location-delivery] request. A location URI [I-D.ietf-geopriv-http-location-delivery] request. A location URI
does not intrinsically include location information, instead the URI does not intrinsically include location information, instead the URI
skipping to change at page 9, line 40 skipping to change at page 9, line 40
generate a HELD error response. For instance, those defined in generate a HELD error response. For instance, those defined in
[I-D.ietf-geopriv-held-identity-extensions] are always invalid and [I-D.ietf-geopriv-held-identity-extensions] are always invalid and
can be rejected. can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet" The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute. associated "exact" attribute.
4.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents, therefore
unless context identifies an "https:" URI as a HELD URI, such a user
agent might simply send an HTTP GET. Rather than providing an HTTP
405 (Method Not Allowed) response indicating that POST is the only
permitted method, this document describes a way for a LIS to provide
a HELD location response if it receives an HTTP GET request.
An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>
Figure 3: GET Request Equivalent Location Request
HTTP GET requests must be safe and idempotent [RFC2616] - that is,
there are no side-effects of making the request. Only when a
location URI is created does HELD request have side-effects. A
request to a location URI can be both safe and idempotent, since a
location URI cannot be produced in response to a request to a
location URI.
Note: Idempotence does not require that the same answer be provided
to different requests only that there are no side effects.
Changes in the response can occur for a number of reasons,
including a change in the value of the resource: the location of
the Target.
Content negotiation MAY be supported to produce a presence document
in place of a HELD location response. Where the presence document
would otherwise be included in a "locationResponse" document, it can
be included in the body of the HTTP response directly.
5. Examples 5. Examples
The example in Figure 3 shows the simplest form of dereferencing The example in Figure 4 shows the simplest form of dereferencing
request using HELD to the location URI request using HELD to the location URI
"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
this differs from the example in Section 10.1 of this differs from the example in Section 10.1 of
[I-D.ietf-geopriv-http-location-delivery] is in the request URI and [I-D.ietf-geopriv-http-location-delivery] is in the request URI and
the source of the URI. the source of the URI.
POST /uri/w3g61nf5n66p0 HTTP/1.1 POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152 Host: ls.example.com:49152
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 3: Minimal Dereferencing Request Figure 4: Minimal Dereferencing Request
Figure 4 shows the response to the previous request listing both Figure 5 shows the response to the previous request listing both
civic and geodetic location information of the Target's location. civic and geodetic location information of the Target's location.
Again, this is identical to the response in Section 10.1 of Again, this is identical to the response in Section 10.1 of
[I-D.ietf-geopriv-http-location-delivery] - unless policy specfies [I-D.ietf-geopriv-http-location-delivery] - unless policy specfies
otherwise, the Location Recipient receives the same information as otherwise, the Location Recipient receives the same information as
the Device. the Device.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Date: Tue, 10 Jan 2009 03:42:29 GMT Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 10 Jan 2009 03:42:29 GMT Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 676
<?xml version="1.0"?> <?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com"> entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd"> <tuple id="b650sf789nd">
<status> <status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10" <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy"> xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
<location-info> <location-info>
<Point xmlns="http://www.opengis.net/gml" <Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326"> srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos> <pos>-34.407 150.88001</pos>
</Point> </Point>
</location-info> </location-info>
<usage-rules> <usage-rules>
<gbp:retransmission-allowed>
false</gbp:retransmission-allowed>
<gbp:retention-expiry> <gbp:retention-expiry>
2006-01-11T03:42:28+00:00</gbp:retention-expiry> 2011-01-11T03:42:29+00:00</gbp:retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
Figure 4: Response with Location Information Figure 5: Response with Location Information
The following GET request is treated in an equivalent fashion. The
LS treats this request as though it were a location request of the
form shown in Figure 3. The same response might be provided.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
Figure 6: GET Request
The following GET request uses content negotiation to indicate a
preference for a presence document.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
Figure 7: GET Request with Content Negotiation
The response only differs from a normal HELD location response to a
POST request in that the "locationResponse" element is omitted and
the "Content-Type" header reflects the changed content.
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
... PIDF contents are identical to the previous example ...
</presence>
Figure 8: GET Response with PIDF-LO
6. Security Considerations 6. Security Considerations
Privacy of location information is the most important security Privacy of location information is the most important security
consideration for this document. Two measures in particular are used consideration for this document. Two measures in particular are used
to protect privacy: TLS and authorization policies. TLS provides a to protect privacy: TLS and authorization policies. TLS provides a
means of ensuring confidentiality of location information through means of ensuring confidentiality of location information through
encryption and mutual authentication. An authorization policy allows encryption and mutual authentication. An authorization policy allows
a Rule Maker to explicitly control how location information is a Rule Maker to explicitly control how location information is
provided to Location Recipients. provided to Location Recipients.
skipping to change at page 14, line 35 skipping to change at page 15, line 39
progress), June 2010. progress), June 2010.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), draft-ietf-geopriv-policy-21 (work in progress),
January 2010. January 2010.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-02 (work in draft-ietf-sipcore-location-conveyance-03 (work in
progress), February 2010. progress), July 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
 End of changes. 15 change blocks. 
28 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/