< draft-ietf-geopriv-http-location-delivery-15.txt   draft-ietf-geopriv-http-location-delivery-16.txt >
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: December 26, 2009 Expires: March 1, 2010
June 24, 2009 Aug 28, 2009
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-15.txt draft-ietf-geopriv-http-location-delivery-16.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2009. This Internet-Draft will expire on March 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 41
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring that the proper LIS has been contacted . . . . . 23 9.1. Assuring that the proper LIS has been contacted . . . . . 23
9.2. Protecting responses from modification . . . . . . . . . . 23 9.2. Protecting responses from modification . . . . . . . . . . 24
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25
10.2. Simple Location Request Example . . . . . . . . . . . . . 27 10.2. Simple Location Request Example . . . . . . . . . . . . . 27
10.3. Location Request Example for Multiple Location Types . . . 28 10.3. Location Request Example for Multiple Location Types . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30
11.3. MIME Media Type Registration for 'application/held+xml' . 30 11.3. MIME Media Type Registration for 'application/held+xml' . 30
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changes since last Version . . . . . . . . . . . . . . . . . . 33 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.1. Normative References . . . . . . . . . . . . . . . . . . . 40 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41
15.2. Informative References . . . . . . . . . . . . . . . . . . 41 15.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 42 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 43
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 43
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 43 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 44
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 43 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 44 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 45
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 45 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 46
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The Location Information Server (LIS) service applies information. The Location Information Server (LIS) service applies
skipping to change at page 6, line 40 skipping to change at page 6, line 40
/ \ _ - - | | APP | | / \ _ - - | | APP | |
Target - - +-----------+ +-----------+ Target - - +-----------+ +-----------+
Figure 1: Significant Roles Figure 1: Significant Roles
The interface between the Location Recipient (LR) and the Device The interface between the Location Recipient (LR) and the Device
and/or LIS is application specific, as indicated by the APP and/or LIS is application specific, as indicated by the APP
annotation in the diagram and it is outside the scope of the annotation in the diagram and it is outside the scope of the
document. An example of an APP interface between a device and LR can document. An example of an APP interface between a device and LR can
be found in the SIP Location Conveyance document be found in the SIP Location Conveyance document
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sipcore-location-conveyance].
4. Protocol Overview 4. Protocol Overview
A device uses the HELD protocol to retrieve its location either A device uses the HELD protocol to retrieve its location either
directly in the form of a Presence Information Data Format Location directly in the form of a Presence Information Data Format Location
Object (PIDF-LO) document (by value) and indirectly as a Location URI Object (PIDF-LO) document (by value) and indirectly as a Location URI
(by reference). The security necessary to ensure the accuracy, (by reference). The security necessary to ensure the accuracy,
privacy and confidentiality of the device's location is described in privacy and confidentiality of the device's location is described in
the Security Considerations (Section 9). the Security Considerations (Section 9).
skipping to change at page 8, line 38 skipping to change at page 8, line 38
NAT that serves a large geographic area or multiple geographic NAT that serves a large geographic area or multiple geographic
locations (for example, a NAT used by an enterprise to connect their locations (for example, a NAT used by an enterprise to connect their
private network to the Internet), the LIS might not be able to return private network to the Internet), the LIS might not be able to return
an accurate LI. If the LIS cannot determine LI for the device, it an accurate LI. If the LIS cannot determine LI for the device, it
should provide an error response to the requesting device. The LIS should provide an error response to the requesting device. The LIS
needs to be configured to recognize identifiers that represent these needs to be configured to recognize identifiers that represent these
conditions. conditions.
LIS operators have a large role in ensuring the best possible LIS operators have a large role in ensuring the best possible
environment for location determination. The LIS operator needs to environment for location determination. The LIS operator needs to
ensure that the LIS is properly configured with identifiers that fall ensure that the LIS is properly configured with identifiers that
within NATs and VPNs. In order to serve a Device on a remote side of indicate Devices on the remote side of a NAT or VPN. In order to
a NAT or VPN a LIS needs to have a presence on the side of the NAT or serve the Devices on the remote side of a NAT or VPN, a LIS needs to
VPN nearest the Device. have a presence on the the side of the NAT or VPN nearest the Device.
4.2. Location by Value 4.2. Location by Value
Where a Device requires LI directly, it can request that the LIS Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations PIDF-LO Usage Clarification, Considerations and Recommendations
skipping to change at page 10, line 24 skipping to change at page 10, line 24
requests is determined by the type of LI that is included in the requests is determined by the type of LI that is included in the
"locationType" element. "locationType" element.
The location request is made by sending a document formed of a The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the "locationRequest" element. The LIS uses the source IP address of the
location request message as the primary source of identity for the location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device requesting device or target. It is anticipated that other Device
identities may be provided through schema extensions. identities may be provided through schema extensions.
The LIS MUST ignore any part of a location request message that it The LIS MUST ignore any part of a location request message that it
does not understand, except the document element. does not understand, except the document element. If the document
element of a request is not supported, the LIS MUST return an error
with the unsupportedMessage error code.
5.2. Location Response 5.2. Location Response
A successful response to a location request MUST contain a PIDF-LO A successful response to a location request MUST contain a PIDF-LO
and/or location URI(s). The response SHOULD contain location and/or location URI(s). The response SHOULD contain location
information of the requested "locationType". The cases whereby a information of the requested "locationType". The cases whereby a
different type of location information MAY be returned are described different type of location information MAY be returned are described
in Section 6.2. in Section 6.2.
5.3. Indicating Errors 5.3. Indicating Errors
skipping to change at page 11, line 41 skipping to change at page 11, line 41
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
6.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" attribute MAY be included in a location request The "responseTime" attribute MAY be included in a location request
message. The "responseTime" attribute includes a time value message. The "responseTime" attribute includes a time value
indicating to the LIS how long the Device is prepared to wait for a indicating to the LIS how long the Device is prepared to wait for a
response or a purpose for which the Device needs the location. response or a purpose for which the Device needs the location.
In the case of emergency services, the purpose of obtaining the LI In the case of emergency services, the purpose of obtaining the LI
could be either for routing a call to the appropriate PSAP or could be either for routing a call to the appropriate Public Safety
indicating the location to which responders should be dispatched. Answering Point (PSAP) or indicating the location to which responders
The values defined for the purpose, "emergencyRouting" and should be dispatched. The values defined for the purpose,
"emergencyDispatch", will likely be governed by jurisdictional "emergencyRouting" and "emergencyDispatch", will likely be governed
policies, and should be configurable on the LIS. by jurisdictional policies, and should be configurable on the LIS.
The time value in the "responseTime" attribute is expressed as a non- The time value in the "responseTime" attribute is expressed as a non-
negative integer in units of milliseconds. The time value is negative integer in units of milliseconds. The time value is
indicative only and the LIS is under no obligation to strictly adhere indicative only and the LIS is under no obligation to strictly adhere
to the time limit implied; any enforcement of the time limit is left to the time limit implied; any enforcement of the time limit is left
to the requesting Device. The LIS provides the most accurate LI that to the requesting Device. The LIS provides the most accurate LI that
can be determined within the specified interval for the specific can be determined within the specified interval for the specific
service. service.
The LIS may use the value of the time in the "responseTime" attribute The LIS may use the value of the time in the "responseTime" attribute
skipping to change at page 14, line 15 skipping to change at page 14, line 15
"exact" attribute were set to "false". "exact" attribute were set to "false".
6.3. "code" Parameter 6.3. "code" Parameter
All "error" responses MUST contain a response code. All errors are All "error" responses MUST contain a response code. All errors are
application-level errors, and MUST only be provided in successfully application-level errors, and MUST only be provided in successfully
processed transport-level responses. For example where HTTP/HTTPS is processed transport-level responses. For example where HTTP/HTTPS is
used as the transport, HELD error messages MUST be carried by a 200 used as the transport, HELD error messages MUST be carried by a 200
OK HTTP/HTTPS response. OK HTTP/HTTPS response.
The value of the response code MUST be one of the following tokens: The value of the response code MUST be an IANA-registered value. The
following tokens are registered by this document:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion (other than the XML content). in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. The same request can be determine the location of the Device. The same request can be
sent by the Device at a later time. Devices MUST limit any sent by the Device at a later time. Devices MUST limit any
skipping to change at page 14, line 50 skipping to change at page 14, line 51
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in for instance, the VPN and NAT scenarios discussed in
Section 4.1.2. Section 4.1.2.
6.4. "message" Parameter 6.4. "message" Parameter
The "error" message MAY include one or more "message" attributes to The "error" message MAY include one or more "message" attributes to
convey some additional, human-readable information about the result convey some additional, human-readable information about the result
of the request. The message MAY be included in any language, which of the request. The message MAY be included in any language, which
SHOULD be indicated by the "xml:lang", attribute. The default SHOULD be indicated by the "xml:lang", attribute. The default
language is assumed to be English. language is assumed to be English ("en") [I-D.ietf-ltru-4646bis].
6.5. "locationUriSet" Parameter 6.5. "locationUriSet" Parameter
The "locationUriSet" element, received in a "locationResponse" The "locationUriSet" element, received in a "locationResponse"
message MAY contain any number of "locationURI" elements. It is message MAY contain any number of "locationURI" elements. It is
RECOMMENDED that the LIS allocate a Location URI for each scheme that RECOMMENDED that the LIS allocate a Location URI for each scheme that
it supports and that each scheme is present only once. URI schemes it supports and that each scheme is present only once. URI schemes
and their secure variants, such as http and https, MUST be regarded and their secure variants, such as http and https, MUST be regarded
as two separate schemes. as two separate schemes.
skipping to change at page 16, line 19 skipping to change at page 16, line 19
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI length of time a location received by dereferencing the location URI
will be valid. The "expires" attribute is RECOMMENDED not to exceed will be valid. The "expires" attribute is RECOMMENDED not to exceed
24 hours and SHOULD be a minimum of 30 minutes. 24 hours and SHOULD be a minimum of 30 minutes.
All date-time values used in HELD MUST be expressed in Universal
Coordinated Time (UTC) using the Gregorian calendar. XML Schema
allows use of time zone identifiers to indicate offsets from the zero
meridian, but this option MUST NOT be used with HELD. The extended
date-time form using upper case "T" and "Z" characters defined in
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
values.
Location responses that contain a "locationUriSet" element MUST Location responses that contain a "locationUriSet" element MUST
include the expiry time in the "expires" attribute. If a Device include the expiry time in the "expires" attribute. If a Device
dereferences a location URI after the expiry time, the dereference dereferences a location URI after the expiry time, the dereference
SHOULD fail. SHOULD fail.
6.6. "Presence" Parameter (PIDF-LO) 6.6. "Presence" Parameter (PIDF-LO)
A single "presence" parameter MAY be included in the A single "presence" parameter MAY be included in the
"locationResponse" message when specific locationTypes (e.g., "locationResponse" message when specific locationTypes (e.g.,
"geodetic" or "civic") are requested or a "locationType" of "any" is "geodetic" or "civic") are requested or a "locationType" of "any" is
skipping to change at page 21, line 17 skipping to change at page 21, line 22
the many options the full HTTP protocol offers. the many options the full HTTP protocol offers.
A Device that conforms to this specification MAY choose not to A Device that conforms to this specification MAY choose not to
support HTTP authentication [RFC2617] or cookies [RFC2965]. Because support HTTP authentication [RFC2617] or cookies [RFC2965]. Because
the Device and the LIS may not necessarily have a prior relationship, the Device and the LIS may not necessarily have a prior relationship,
the LIS SHOULD NOT require a Device to authenticate, either using the the LIS SHOULD NOT require a Device to authenticate, either using the
above HTTP authentication methods or TLS client authentication. above HTTP authentication methods or TLS client authentication.
Unless all Devices that access a LIS can be expected to be able to Unless all Devices that access a LIS can be expected to be able to
authenticate in a certain fashion, denying access to location authenticate in a certain fashion, denying access to location
information could prevent a Device from using location-dependent information could prevent a Device from using location-dependent
services, such as emergency calling. services, such as emergency calling. Extensions to this protocol
might result in the addition of request parameters that a LIS might
use to decide to request Device authentication.
A HELD request is carried in the body of an HTTP POST request. The A HELD request is carried in the body of an HTTP POST request. The
Device MUST include a Host header in the request. Device MUST include a Host header in the request.
The MIME type of HELD request and response bodies is The MIME type of HELD request and response bodies is
"application/held+xml". LIS and Device MUST provide this value in "application/held+xml". LIS and Device MUST provide this value in
the HTTP Content-Type and Accept header fields.If the LIS does not the HTTP Content-Type and Accept header fields.If the LIS does not
receive the appropriate Content-Type and Accept header fields, the receive the appropriate Content-Type and Accept header fields, the
LIS SHOULD fail the request, returning a 406 (not acceptable) LIS SHOULD fail the request, returning a 406 (not acceptable)
response. HELD responses SHOULD include a Content-Length header. response. HELD responses SHOULD include a Content-Length header.
skipping to change at page 22, line 24 skipping to change at page 22, line 31
Device SHOULD authenticate the LIS indicated in a redirect. Device SHOULD authenticate the LIS indicated in a redirect.
The LIS SHOULD support persistent connections and request pipelining. The LIS SHOULD support persistent connections and request pipelining.
If pipelining is not supported, the LIS MUST NOT allow persistent If pipelining is not supported, the LIS MUST NOT allow persistent
connections. The Device MUST support termination of a response by connections. The Device MUST support termination of a response by
the closing of a connection. the closing of a connection.
Implementations of HELD that implement HTTP transport MUST implement Implementations of HELD that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between Device and LIS. The Device MUST implement confidentiality between Device and LIS. The Device MUST implement
the server authentication method described in HTTPS [RFC2818]. The the server authentication method described in Section 3.1 of
device uses the URI obtained during LIS discovery to authenticate the [RFC2818], with an exception in how wildcards are handled. The
server. The details of this authentication method are provided in leftmost label MAY contain the wildcard string "*", which matches any
section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD single domain name label. Additional characters in this leftmost
fail a request if server authentication fails, except in the event of label are invalid (that is, "f*.example.com" is not a valid name and
an emergency. does not match any domain name).
The device uses the URI obtained during LIS discovery to authenticate
the server. The details of this authentication method are provided
in section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device
SHOULD fail a request if server authentication fails, except in the
event of an emergency.
9. Security Considerations 9. Security Considerations
HELD is a location acquisition protocol whereby the a client requests HELD is a location acquisition protocol whereby the a client requests
its location from a LIS. Specific requirements and security its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in considerations for location acquisition protocols are provided in
[I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
considerations applicable to the use of Location URIs and by considerations applicable to the use of Location URIs and by
reference provision of LI is included in reference provision of LI is included in
[I-D.ietf-geopriv-lbyr-requirements]. [I-D.ietf-geopriv-lbyr-requirements].
By using the HELD protocol, the client and the LIS expose themselves By using the HELD protocol, the client and the LIS expose themselves
to two types of risk: to two types of risk:
Accuracy: Client receives incorrect location information Accuracy: Client receives incorrect location information
Privacy: An unauthorized entity receives location information Privacy: An unauthorized entity receives location information
The provision of an accurate and privacy/confidentiality protected The provision of an accurate and privacy/confidentiality protected
location to the requestor depends on the success of five steps: location to the requestor depends on the success of five steps:
skipping to change at page 25, line 31 skipping to change at page 25, line 43
10.1. HTTPS Example Messages 10.1. HTTPS Example Messages
The examples in this section show complete HTTP/HTTPS messages that The examples in this section show complete HTTP/HTTPS messages that
include the HELD request or response document. include the HELD request or response document.
This example shows the most basic request for a LO. The POST This example shows the most basic request for a LO. The POST
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST /location HTTP/1.1 POST /location HTTP/1.1
Host: lis.example.com:49152 Host: lis.example.com:49152
Content-Type: application/held+xml Content-Type: application/held+xml;charset=utf-8
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"/>
Since the above request does not include a "locationType" element, Since the above request does not include a "locationType" element,
the successful response to the request may contain any type of the successful response to the request may contain any type of
location. The following shows a response containing a minimal location. The following shows a response containing a minimal
PIDF-LO. PIDF-LO.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml;charset=utf-8
Content-Length: 594 Content-Length: 856
<?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">
<location-info> <location-info>
<Point xmlns="http://www.opengis.net/gml" <Point xmlns="http://www.opengis.net/gml"
skipping to change at page 27, line 12 skipping to change at page 27, line 12
</presence> </presence>
</locationResponse> </locationResponse>
The error response to the request is an error document. The The error response to the request is an error document. The
following response shows an example error response. following response shows an example error response.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml;charset=utf-8
Content-Length: 135 Content-Length: 182
<?xml version="1.0"?> <?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"> code="locationUnknown">
<message xml:lang="en">Unable to determine location <message xml:lang="en">Unable to determine location
</message> </message>
</error> </error>
10.2. Simple Location Request Example 10.2. Simple Location Request Example
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of The example response to this location request contains a list of
Location URIs. Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"/> code="locationUnknown"/>
skipping to change at page 28, line 29 skipping to change at page 28, line 29
geodetic geodetic
civic civic
locationURI locationURI
</locationType> </locationType>
</locationRequest> </locationRequest>
The corresponding Location Response message includes the requested The corresponding Location Response message includes the requested
location information, including two location URIs. location information, including two location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"> <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
skipping to change at page 31, line 6 skipping to change at page 31, line 6
11.3. MIME Media Type Registration for 'application/held+xml' 11.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Same as the charset parameter of "application/xml" as specified in
UTF-8. RFC 3023 [RFC3023], section 3.2.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Same as the encoding considerations of
characters, depending on the character encoding used. See RFC "application/xml" as specified in RFC 3023 [RFC3023], section 3.2.
3023 [RFC3023], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could protocol data related to the location of an entity, which could
include information that is considered private. Appropriate include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this precautions should be taken to limit disclosure of this
information. information.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Location information Applications which use this media type: Location information
providers and consumers. providers and consumers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/held+xml. described there also apply to application/held+xml.
11.4. Error code Registry 11.4. Error code Registry
skipping to change at page 33, line 4 skipping to change at page 33, line 4
section. In addition, they also contributed to the WG document, section. In addition, they also contributed to the WG document,
including the XML schema. including the XML schema.
13. Acknowledgements 13. Acknowledgements
The author/contributors would like to thank the participants in the The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott, feedback on this document (in alphabetical order): Nadine Abbott,
Bernard Aboba, Eric Arolick, Richard Barnes (in particular the Bernard Aboba, Eric Arolick, Richard Barnes (in particular the
security section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy security section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy
Corbett, Martin Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Corbett, Martin Dawson, Lisa Dusseault, Robins George, Jerome
Cullen Jennings, Neil Justusson, Tat Lam, Marc Linsner, Patti Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Julian Linsner, Patti McCalmont, Alexey Melnikov, Roger Marshall, Tim Polk,
Reschke, Eric Rescorla, Brian Rosen, John Schnizlein, Shida Schubert, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Dan
Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig and Romascanu, Brian Rosen, John Schnizlein, Shida Schubert, Henning
Karl Heinz Wolf. Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz
Wolf.
14. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from 15 to 16(IESG Review DISCUSSES/comments):
1) Editorial Clarifications.
2) Section 6.4 added explicit reference to draft-ietf-ltru-4646bis
3) Section 6.5.3/examples (Expiry Time): clarified the details (UTC/
Gregorian calendar) for the expiry time and updated examples to
include fractional seconds and trailing 'Z'.
4) Section 8: Clarified the usage of wildcards in the domain name for
server authentication.
5) Section 10.1: Fixed examples - added charset attribute to Content
Type and fixed lengths
6) Section 11.3 (IANA mime registration), replaced text for Optional
paramters and Encoding considerations with references to RFC 3023.
Fixed Macintosh File Type Code.
7) Updated location-conveyance reference to SIPCORE document.
Changes from 14 to 15(Gen-Art and IETF discussion ML comments post Changes from 14 to 15(Gen-Art and IETF discussion ML comments post
3rd IETF LC): 3rd IETF LC):
1) Clarification around device support for cookies or basic/digest 1) Clarification around device support for cookies or basic/digest
authentication. authentication.
2)Additional text in section 6.3 (PIDF-LO) around the LIS including 2)Additional text in section 6.3 (PIDF-LO) around the LIS including
(and not including) any information identifying the device in the (and not including) any information identifying the device in the
returned PIDF-LO. returned PIDF-LO.
skipping to change at page 41, line 4 skipping to change at page 41, line 30
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
skipping to change at page 41, line 50 skipping to change at page 42, line 28
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[I-D.ietf-ltru-4646bis]
Phillips, A. and M. Davis, "Tags for Identifying
Languages", draft-ietf-ltru-4646bis-23 (work in progress),
June 2009.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006. July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), February 2009. progress), July 2009.
[I-D.ietf-geopriv-lbyr-requirements] [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work
in progress), February 2009. in progress), February 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sipcore-location-conveyance-01 (work in
March 2009. progress), July 2009.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in the [I-D.ietf-geopriv-l7-lcp-ps].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
 End of changes. 34 change blocks. 
59 lines changed or deleted 106 lines changed or added

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