draft-ietf-geopriv-http-location-delivery-11.txt   draft-ietf-geopriv-http-location-delivery-12.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: June 19, 2009 Expires: July 31, 2009
December 16, 2008 January 27, 2009
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-11.txt draft-ietf-geopriv-http-location-delivery-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
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."
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 June 19, 2009. This Internet-Draft will expire on July 31, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 32 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring that the proper LIS has been contacted . . . . . 22 9.1. Assuring that the proper LIS has been contacted . . . . . 23
9.2. Protecting responses from modification . . . . . . . . . . 22 9.2. Protecting responses from modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25
10.2. Simple Location Request Example . . . . . . . . . . . . . 26 10.2. Simple Location Request Example . . . . . . . . . . . . . 27
10.3. Location Request Example for Multiple Location Types . . . 27 10.3. Location Request Example for Multiple Location Types . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . 28 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30
11.3. MIME Media Type Registration for 'application/held+xml' . 29 11.3. MIME Media Type Registration for 'application/held+xml' . 30
11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changes since last Version . . . . . . . . . . . . . . . . . . 32 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 40 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 40 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 40 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 41
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 41 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 41 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 42 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 42 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 43
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 43 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 43 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
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
information. The Location Information Server (LIS) service applies information. The Location Information Server (LIS) service applies
to access networks employing both wired technology (e.g. DSL, Cable) to access networks employing both wired technology (e.g. DSL, Cable)
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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 URI for the for the LIS for sending the HELD protocol requests. The URI for the
LIS SHOULD be obtained from an authorized and authenticated entity. LIS SHOULD be obtained from an authorized and authenticated entity.
The details for ensuring that an appropriate LIS is contacted are The details for ensuring that an appropriate LIS is contacted are
provided in Section 9 and in particular Section 9.1. The LIS provided in Section 9 and in particular Section 9.1. The LIS
discovery protocol details are out of scope of this document and are discovery protocol details are out of scope of this document and are
specified in [I-D.ietf-geopriv-lis-discovery]. The type of URI specified in [I-D.ietf-geopriv-lis-discovery]. The type of URI
provided by LIS discovery is RECOMMENDED not be a general HTTP URI. provided by LIS discovery is RECOMMENDED to be an https: 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 29 skipping to change at page 10, line 29
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 RECOMMENDS 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 [RFC5246] 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
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
skipping to change at page 20, line 28 skipping to change at page 20, line 28
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
8. HTTP/HTTPS Binding 8. HTTP Binding
This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818] This section describes the use of HTTP [RFC2616] and HTTP Over TLS
as transport mechanisms for the HELD protocol, which all conforming [RFC2818] as transport mechanisms for the HELD protocol, which a
implementations MUST support. conforming LIS and Device MUST support.
The request is carried in the body of an HTTP/HTTPS POST request. Although HELD uses HTTP as a transport, it uses a strict subset of
The MIME type of both request and response bodies should be HTTP features, and due to the restrictions of some features, a LIS is
"application/held+xml". This should be reflected in the HTTP not a fully compliant HTTP server. It is intended that a LIS can
Content-Type and Accept header fields. easily be built using an HTTP server with extensibility mechanisms,
and that a HELD Device can trivially use existing HTTP libraries.
This subset of requirements helps implementors avoid ambiguity with
the many options the full HTTP protocol offers. The LIS MUST NOT
rely on device support for cookies [RFC2965] or use Basic or Digest
authentication [RFC2617].
The LIS populates the HTTP/HTTPS headers so that they are consistent A HELD request is carried in the body of an HTTP POST request. The
with the contents of the message. In particular, the cache control Device MUST include a Host header in the request.
header SHOULD be set to disable the HTTP/HTTPS caching of any PIDF-LO
document or Location URIs. Otherwise, there is the risk of stale
locations and/or the unauthorized disclosure of the LI. This also
allows the LIS to control any caching with the "expires" parameter.
The HTTP/HTTPS status code MUST indicate a 2xx series response for
all HELD locationResponse and error messages.
The use of HTTP/HTTPS also includes a default behaviour, which is The MIME type of HELD request and response bodies is
triggered by a GET request, or a POST with no request body. If "application/held+xml". LIS and Device MUST provide this value in
either of these queries are received, the LIS MUST attempt to provide the HTTP Content-Type and Accept header fields.If the LIS does not
either a PIDF-LO document or a Location URI, as if the request was a receive the appropriate Content-Type and Accept header fields, the
location request. LIS SHOULD fail the request, returning a 406 (not acceptable)
response. HELD responses SHOULD include a Content-Length header.
Implementation of HELD that implement HTTP transport MUST implement a Devices MUST NOT use the "Expect" header or the "Range" header in
transport over HTTPS [RFC2818]. TLS provides message integrity and HELD requests. The LIS MAY return 501 (not implemented) errors if
confidentiality between Device and LIS. The LIS MUST implement the either of these HTTP features are used. In the case that the LIS
server authentication method described in [RFC2818]. The device uses receives a request from the Device containing a If-* (conditional)
the URI obtained during LIS discovery to authenticate the server. header, the LIS SHOULD return a 412 (precondition failed) response.
The details of this authentication method are provided in section 3.1
of [RFC2818]. When TLS is used, the Device SHOULD fail a request if The POST method is the only method REQUIRED for HELD. If a LIS
server authentication fails, except in the event of an emergency. chooses to support GET or HEAD, it SHOULD consider the kind of
application doing the GET. Since a HELD Device only uses a POST
method, the GET or HEAD MUST be either an escaped URL (e.g., somebody
found a URL in protocol traces or log files and fed it into their
browser) or somebody doing testing/ debugging. The LIS could provide
information in the HELD response indicating that the URL corresponds
to a LIS server and only responds to HELD POST requests or the LIS
could instead try to avoid any leak of information by returning a
very generic HTTP error message such as 404 (not found).
The LIS populates the HTTP headers of responses so that they are
consistent with the contents of the message. In particular, the
"CacheControl" header SHOULD be set to disable caching of any PIDF-LO
document or Location URIs by HTTP intermediaries. Otherwise, there
is the risk of stale locations and/or the unauthorized disclosure of
the LI. This also allows the LIS to control any caching with the
HELD "expires" parameter. The HTTP status code MUST indicate a 2xx
series response for all HELD locationResponse and HELD error
messages.
The LIS MAY redirect a HELD request. A Device MUST handle redirects,
by using the Location header provided by the server in a 3xx
response. When redirecting, the Device MUST observe the delay
indicated by the Retry-After header. The Device MUST authenticate
the server that returns the redirect response before following the
redirect. A Device SHOULD authenticate the LIS indicated in a
redirect.
The LIS SHOULD support persistent connections and request pipelining.
If pipelining is not supported, the LIS MUST NOT allow persistent
connections. The Device MUST support termination of a response by
the closing of a connection.
The use of HTTP also includes a default behaviour, which is triggered
by a POST with no request body. If either of these queries are
received, the LIS MUST attempt to provide either a PIDF-LO document
or a Location URI, as if the request was a location request.
Implementations of HELD that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between Device and LIS. The Device MUST implement
the server authentication method described in HTTPS [RFC2818]. 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].
skipping to change at page 22, line 12 skipping to change at page 23, line 11
considerations are already discussed. The fourth step is dependent considerations are already discussed. The fourth step is dependent
on the specific positioning capabilities of the LIS, and is thus on the specific positioning capabilities of the LIS, and is thus
outside the scope of this document. outside the scope of this document.
9.1. Assuring that the proper LIS has been contacted 9.1. Assuring that the proper LIS has been contacted
This document assumes that the LIS to be contacted is identified This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery discovered as described in LIS Discovery
[I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
conducted using TLS [RFC4346], the LIS can authenticate its identity, conducted using TLS [RFC5246], the LIS can authenticate its identity,
either as a domain name or as an IP address, to the client by either as a domain name or as an IP address, to the client by
presenting a certificate containing that identifier as a presenting a certificate containing that identifier as a
subjectAltName (i.e., as an iPAddress or dNSName, respectively). In subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
the case of the HTTP binding described above, this is exactly the the case of the HTTP binding described above, this is exactly the
authentication described by TLS [RFC2818]. Any binding of HELD MUST authentication described by TLS [RFC2818]. If the client has
be capable of being transacted over TLS so that the client can external information as to the expected identity or credentials of
request the above authentication, and a LIS implementation for a the proper LIS (e.g., a certificate fingerprint), these checks MAY be
binding MUST include this feature. Note that in order for the omitted. Any binding of HELD MUST be capable of being transacted
presented certificate to be valid at the client, the client must be over TLS so that the client can request the above authentication, and
able to validate the certificate. In particular, the validation path a LIS implementation for a binding MUST include this feature. Note
of the certificate must end in one of the client's trust anchors, that in order for the presented certificate to be valid at the
even if that trust anchor is the LIS certificate itself. client, the client must be able to validate the certificate. In
particular, the validation path of the certificate must end in one of
the client's trust anchors, even if that trust anchor is the LIS
certificate itself.
9.2. Protecting responses from modification 9.2. Protecting responses from modification
In order to prevent that response from being modified en route, In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel. messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature When the transaction is being conducted over TLS (a required feature
per Section 9.1), the channel will be integrity protected by per Section 9.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route. TLS, the response will not be protected from modification en route.
skipping to change at page 24, line 13 skipping to change at page 25, line 14
with comments. with comments.
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 HTTPS/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
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.
HTTPS/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
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 7 skipping to change at page 27, line 7
<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 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.
HTTPS/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
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 33, 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 11 to 12 (Post-2nd WGLC):
1) Expanded text in section 8 (HTTP binding) to provide more detail
about the requirements for an HTTP implementation supporting HELD.
Clarified the mandatory functionality and specific handling of other
functionality of HTTP.
2) Clarification in section 9.1 for clients that have external info
wrt the identity or credentials of the LIS.
3) More nits.
Changes from WG 10 to 11 (Post-2nd WGLC): Changes from WG 10 to 11 (Post-2nd WGLC):
1) Added additional text around the scope and applicability of the 1) Added additional text around the scope and applicability of the
URI returned from LIS Discovery (section 4). URI returned from LIS Discovery (section 4).
2) Removed HTTP GET - will always use POST. 2) Removed HTTP GET - will always use POST.
3) Removed sentence wrt mobile devices in section 6.2. 3) Removed sentence wrt mobile devices in section 6.2.
4) Added specific recommendation for minimum value for expires in 4) Added specific recommendation for minimum value for expires in
skipping to change at page 38, line 10 skipping to change at page 39, line 18
10) Miscellaneous editorial clarifications. 10) Miscellaneous editorial clarifications.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, 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.
[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-14 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 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, 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]
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-04 (work in progress), draft-ietf-geopriv-lis-discovery-05 (work in progress),
October 2008. December 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 21 skipping to change at page 40, line 38
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.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 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-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008. progress), June 2008.
skipping to change at page 45, line 4 skipping to change at line 2007
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Barbara Stark Barbara Stark
BellSouth BellSouth
Room 7A43 Room 7A43
725 W Peachtree St. 725 W Peachtree St.
Atlanta, GA 30308 Atlanta, GA 30308
US US
Email: barbara.stark@att.com Email: barbara.stark@att.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 27 change blocks. 
93 lines changed or deleted 167 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/