draft-ietf-geopriv-http-location-delivery-10.txt   draft-ietf-geopriv-http-location-delivery-11.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: May 2, 2009 Expires: June 19, 2009
October 29, 2008 December 16, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-10.txt draft-ietf-geopriv-http-location-delivery-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 2, 2009. This Internet-Draft will expire on June 19, 2009.
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
skipping to change at page 2, line 31 skipping to change at page 2, line 31
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Assuring that the proper LIS has been contacted . . . . . 22 9.1. Assuring that the proper LIS has been contacted . . . . . 22
9.2. Protecting responses from modification . . . . . . . . . . 22 9.2. Protecting responses from modification . . . . . . . . . . 22
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24
10.2. Simple Location Request Example . . . . . . . . . . . . . 26 10.2. Simple Location Request Example . . . . . . . . . . . . . 26
10.3. Location Request Example for Multiple Location Types . . . 27 10.3. Location Request Example for Multiple Location Types . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29 11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
14. Changes since last Version . . . . . . . . . . . . . . . . . . 32 14. Changes since last Version . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 40
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 40
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 40 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 40
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 40 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 41
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 41 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 41
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 42
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 42 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 42
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 43
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . . . 45
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
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 PIDF-LO document (by value) and indirectly directly in the form of a PIDF-LO document (by value) and indirectly
as a Location URI (by reference). The security necessary to ensure as a Location URI (by reference). The security necessary to ensure
the accuracy, privacy and confidentiality of the device's location is the accuracy, privacy and confidentiality of the device's location is
described in the Security Considerations (Section 9). described in the Security Considerations (Section 9).
As described in the L7 LCP problem statement and requirements As described in the L7 LCP problem statement and requirements
[I-D.ietf-geopriv-l7-lcp-ps], the Device must first discover the URI [I-D.ietf-geopriv-l7-lcp-ps], the Device MUST first discover the URI
for the LIS for sending the HELD protocol requests. The discovery for the LIS for sending the HELD protocol requests. The URI for the
methods are specified in [I-D.ietf-geopriv-lis-discovery]. LIS SHOULD be obtained from an authorized and authenticated entity.
The details for ensuring that an appropriate LIS is contacted are
provided in Section 9 and in particular Section 9.1. The LIS
discovery protocol details are out of scope of this document and are
specified in [I-D.ietf-geopriv-lis-discovery]. The type of URI
provided by LIS discovery is RECOMMENDED not be a general HTTP URI.
The LIS requires an identifier for the Device in order to determine The LIS requires an identifier for the Device in order to determine
the appropriate location to include in the location response message. the appropriate location to include in the location response message.
In this document, the IP address of the Device, as reflected by the In this document, the IP address of the Device, as reflected by the
source IP address in the location request message, is used as the source IP address in the location request message, is used as the
identifier. Other identifiers are possible, but are beyond the scope identifier. Other identifiers are possible, but are beyond the scope
of this document. of this document.
4.1. Device Identifiers, NAT and VPNs 4.1. Device Identifiers, NAT and VPNs
skipping to change at page 10, line 23 skipping to change at page 10, line 24
XML document. The HELD protocol is defined independently of any XML document. The HELD protocol is defined independently of any
lower layers used to transport messages from one host to another. lower layers used to transport messages from one host to another.
This means that any protocol can be used to transport this protocol This means that any protocol can be used to transport this protocol
providing that it can provide a few basic features: providing that it can provide a few basic features:
o The HELD protocol doesn't provide any mechanisms that enable o The HELD protocol doesn't provide any mechanisms that enable
detection of missing messages and retransmission, thus the detection of missing messages and retransmission, thus the
protocol must have acknowledged delivery. protocol must have acknowledged delivery.
o The HELD protocol is a request/response protocol, thus the o The HELD protocol is a request/response protocol, thus the
protocol must be able to correlate a response with a request. protocol must be able to correlate a response with a request.
o The HELD protocol REQUIRES that the underlying transport provide o The HELD protocol RECOMMENDS that the underlying transport provide
authentication, confidentiality, and protection against authentication, confidentiality, and protection against
modification per Section 9.3. modification per Section 9.3.
This document describes the use of a combination of HTTP [RFC2616], This document describes the use of a combination of HTTP [RFC2616],
TLS [RFC4346] and TCP [RFC0793] in Section 8. TLS [RFC4346] and TCP [RFC0793] in Section 8.
5.2. Location Request 5.2. Location Request
A location request message is sent from the Device to the LIS when A location request message is sent from the Device to the LIS when
the Device requires its own LI. The type of LI that a Device the Device requires its own LI. The type of LI that a Device
skipping to change at page 13, line 23 skipping to change at page 13, line 23
prefers a specific location type without causing location requests to prefers a specific location type without causing location requests to
fail when that location type is unavailable. For example, a notebook fail when that location type is unavailable. For example, a notebook
computer could be configured to retrieve civic addresses, which is computer could be configured to retrieve civic addresses, which is
usually available from typical home or work situations. However, usually available from typical home or work situations. However,
when using a wireless modem, the LIS might be unable to provide a when using a wireless modem, the LIS might be unable to provide a
civic address and thus provides a geodetic address. civic address and thus provides a geodetic address.
The LIS SHOULD return location information in a form that is suited The LIS SHOULD return location information in a form that is suited
for routing and responding to an emergency call in its jurisdiction, for routing and responding to an emergency call in its jurisdiction,
specifically by value. The LIS MAY alternatively or additionally specifically by value. The LIS MAY alternatively or additionally
return a location URI. If the LIS believes that the Device is return a location URI. If the "locationType" element is absent, a
mobile, that is, its location may change over relatively short location URI MUST be assumed as the default. A location URI provided
periods of time (i.e., several minutes), it SHOULD return a location by the LIS is a reference to the most current available LI and is not
URI. If the "locationType" element is absent, a location URI MUST be a stable reference to a specific location.
assumed as the default. A location URI provided by the LIS is a
reference to the most current available LI and is not a stable
reference to a specific location.
It should be noted that the protocol does not support a request to It should be noted that the protocol does not support a request to
just receive one of a subset of location types. For example, in the just receive one of a subset of location types. For example, in the
case where a Device has a preference for just "geodetic" or "civic", case where a Device has a preference for just "geodetic" or "civic",
it is necessary to make the request without an "exact" attribute, it is necessary to make the request without an "exact" attribute,
including both location types. In this case, if neither is available including both location types. In this case, if neither is available
a LIS SHOULD return a locationURI if available. a LIS SHOULD return a locationURI if available.
The LIS SHOULD provide the locations in the response in the same The LIS SHOULD provide the locations in the response in the same
order in which they were included in the "locationType" element in order in which they were included in the "locationType" element in
skipping to change at page 16, line 29 skipping to change at page 16, line 24
in Section 9.3. in Section 9.3.
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 several minutes. 24 hours and SHOULD be a minimum of 30 minutes.
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 "presence" parameter may be included in the "locationResponse" A single "presence" parameter MAY be included in the
message when specific locationTypes (e.g., "geodetic" or "civic") are "locationResponse" message when specific locationTypes (e.g.,
requested or a "locationType" of "any" is requested. The LIS MUST "geodetic" or "civic") are requested or a "locationType" of "any" is
follow the subset of the rules relating to the construction of the requested. The LIS MUST follow the subset of the rules relating to
"location-info" element in the PIDF-LO Usage Clarification, the construction of the "location-info" element in the PIDF-LO Usage
Considerations and Recommendations document Clarification, Considerations and Recommendations document
[I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the [I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the
presence parameter. presence parameter.
Note that the presence parameter is not explicitly shown in the XML Note that the presence parameter is not explicitly shown in the XML
schema in Section 7 for a location response message, due to XML schema in Section 7 for a location response message, due to XML
schema constraints, since PIDF is already defined and registered schema constraints, since PIDF is already defined and registered
separately. Thus, the "##other" namespace serves as a placeholder separately. Thus, the "##other" namespace serves as a placeholder
for the presence parameter in the schema. for the presence parameter in the schema.
7. XML Schema 7. XML Schema
skipping to change at page 23, line 32 skipping to change at page 23, line 29
could request a Location Object or Location URI that would result in could request a Location Object or Location URI that would result in
another Device's location. In addition, in cases where a Device another Device's location. In addition, in cases where a Device
drops off the network for various reasons, the re-use of the Device's drops off the network for various reasons, the re-use of the Device's
IP address could result in another Device receiving the original IP address could result in another Device receiving the original
Device's location rather than its own location. These exposures are Device's location rather than its own location. These exposures are
limited by the following: limited by the following:
o Location URIs MUST have a limited lifetime, as reflected by the o Location URIs MUST have a limited lifetime, as reflected by the
value for the expires element in Section 6.5.2. The lifetime of value for the expires element in Section 6.5.2. The lifetime of
location URIs necessarily depends on the nature of the access. location URIs necessarily depends on the nature of the access.
o The network SHOULD have mechanisms that protect against IP address
spoofing, such as those defined in [RFC3704].
o The LIS and network SHOULD be configured so that the LIS is made o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network that results changes. If the LIS detects a change in the network that results
in it no longer being able to determine the location of the in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be Device, then all location URIs for that Device SHOULD be
invalidated. invalidated.
The above measures are dependent on network configuration, which The above measures are dependent on network configuration, which
SHOULD be considered. For instance, in a fixed internet access, SHOULD be considered. For instance, in a fixed internet access,
providers may be able to restrict the allocation of IP addresses to a providers may be able to restrict the allocation of IP addresses to a
skipping to change at page 24, line 12 skipping to change at page 24, line 7
The following sections provide basic HTTP/HTTPS examples, a simple The following sections provide basic HTTP/HTTPS examples, a simple
location request example and a location request for multiple location location request example and a location request for multiple location
types example along with the relevant location responses. To focus types example along with the relevant location responses. To focus
on important portions of messages, the examples in Section 10.2 and on important portions of messages, the examples in Section 10.2 and
Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In
addition, sections of XML not relevant to the example are replaced addition, sections of XML not relevant to the example are replaced
with comments. with comments.
10.1. HTTPS Example Messages 10.1. HTTPS Example Messages
The examples in this section show a complete HTTPS message that The examples in this section show complete HTTP/HTTPS messages that
includes the HELD request or response document. include the HELD request or response document.
This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding.
GET /location HTTP/1.1
Host: lis.example.com:49152
The GET request is exactly identical to a minimal POST request that 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 HTTPS/1.1
Host: lis.example.com:49152 Host: lis.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"/>
Since neither of these requests includes a "locationType" element, Since the above request does not include a "locationType" element,
the successful response to either of these requests may contain any the successful response to the request may contain any type of
type of location. The following shows a response containing a location. The following shows a response containing a minimal
minimal PIDF-LO. PIDF-LO.
HTTP/1.1 200 OK HTTPS/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
Content-Length: 594 Content-Length: 594
<?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"
skipping to change at page 26, line 4 skipping to change at page 26, line 4
<retention-expiry> <retention-expiry>
2006-01-11T03:42:28+00:00</retention-expiry> 2006-01-11T03:42:28+00:00</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>
The error response to either of these requests is an error document. The error response to the request is an error document. The
The following response shows an example error response. following response shows an example error response.
HTTP/1.1 200 OK HTTPS/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
Content-Length: 135 Content-Length: 135
<?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="Unable to determine location"/> message="Unable to determine location"/>
skipping to change at page 32, line 15 skipping to change at page 32, line 15
Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger
Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla,
Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. 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 WG 10 to 11 (Post-2nd WGLC):
1) Added additional text around the scope and applicability of the
URI returned from LIS Discovery (section 4).
2) Removed HTTP GET - will always use POST.
3) Removed sentence wrt mobile devices in section 6.2.
4) Added specific recommendation for minimum value for expires in
section 6.5.2 (30 Minutes).
5) Remove reference to RFC 3704 (for IP address spoofing) in section
9.3 (bullet 2).
6) Clarified that both HTTP and HTTPS are allowed - changed last
bullet in section 5.1 from REQUIRES to RECOMMENDS.
7) Clarification wrt "presence" parameter in section 6.6 - a "single"
presence parameter may be included.
Changes from WG 09 to 10 (2nd WGLC): Changes from WG 09 to 10 (2nd WGLC):
1) Updated text for Devices and VPNs (section 4.1.1) to include 1) Updated text for Devices and VPNs (section 4.1.1) to include
servers such as HTTP and SOCKs, thus changed the text to be generic servers such as HTTP and SOCKs, thus changed the text to be generic
in terms of locating LIS before connecting to one of these servers, in terms of locating LIS before connecting to one of these servers,
etc. etc.
2) Fixed (still buggy) HTTP examples. 2) Fixed (still buggy) HTTP examples.
3) Added text explaining the whitespaces in XML schema are for 3) Added text explaining the whitespaces in XML schema are for
skipping to change at page 37, line 45 skipping to change at page 38, line 22
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-13 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), September 2008. (work in progress), November 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney,
"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]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "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>.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-03 (work in progress), draft-ietf-geopriv-lis-discovery-04 (work in progress),
September 2008. October 2008.
15.2. Informative References 15.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
skipping to change at page 39, line 17 skipping to change at page 39, line 37
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-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008. progress), June 2008.
[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-03 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work
in progress), July 2008. in progress), November 2008.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-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-10 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
September 2008. November 2008.
[I-D.winterbottom-geopriv-deref-protocol] [I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD", Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-02 (work in draft-winterbottom-geopriv-deref-protocol-02 (work in
progress), July 2008. progress), July 2008.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
 End of changes. 29 change blocks. 
62 lines changed or deleted 74 lines changed or added

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