draft-ietf-geopriv-http-location-delivery-14.txt   draft-ietf-geopriv-http-location-delivery-15.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: November 12, 2009 Expires: December 26, 2009
May 11, 2009 June 24, 2009
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-14.txt draft-ietf-geopriv-http-location-delivery-15.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 November 12, 2009. This Internet-Draft will expire on December 26, 2009.
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 37 skipping to change at page 2, line 37
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . 22 9.1. Assuring that the proper LIS has been contacted . . . . . 23
9.2. Protecting responses from modification . . . . . . . . . . 23 9.2. Protecting responses from modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . . 40 15.1. Normative References . . . . . . . . . . . . . . . . . . . 40
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 . . . . . . 42
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 42 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 . . . . 43
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 43 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 43
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 . . . . . . . . . . . . . . . . . . . 44
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . . 45
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 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
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 5, line 16 skipping to change at page 5, line 16
In describing the protocol, the terms "attribute" and "element" are In describing the protocol, the terms "attribute" and "element" are
used according to their context in XML. The term "parameter" is used used according to their context in XML. The term "parameter" is used
in a more general protocol context and can refer to either an XML in a more general protocol context and can refer to either an XML
"attribute" or "element". "attribute" or "element".
3. Overview and Scope 3. Overview and Scope
This document describes an interface between a Device and a Location This document describes an interface between a Device and a Location
Information Server (LIS). This document assumes that the LIS is Information Server (LIS). This document assumes that the LIS is
present within the same administrative domain as the Device (e.g., present within the same administrative domain as the Device (e.g.,
the access network). An Access Provider (AP) operates the LIS so the access network). The LIS exists because not all Devices are
that Devices (and Targets) can retrieve their LI. The LIS exists capable of determining LI, and because, even if a device is able to
because not all Devices are capable of determining LI, and because, determine its own LI, it may be more efficient with assistance. This
even if a device is able to determine its own LI, it may be more document does not specify how LI is determined. An Access Provider
efficient with assistance. This document does not specify how LI is (AP) operates the LIS so that Devices (and Targets) can retrieve
determined. their LI. This document assumes that the Device and Access Provider
have no prior relationship other than what is necessary for the
Device to obtain network access.
This document is based on the attribution of the LI to a Device and This document is based on the attribution of the LI to a Device and
not specifically a person (end user) or Target, based on the premise not specifically a person (end user) or Target, based on the premise
that location determination technologies are generally designed to that location determination technologies are generally designed to
locate a device and not a person. It is expected that, for most locate a device and not a person. It is expected that, for most
applications, LI for the device can be used as an adequate substitute applications, LI for the device can be used as an adequate substitute
for the end user's LI. Since revealing the location of the device for the end user's LI. Since revealing the location of the device
almost invariably reveals some information about the location of the almost invariably reveals some information about the location of the
user of the device, the same level of privacy protection demanded by user of the device, the same level of privacy protection demanded by
a user is required for the device. This approach may require either a user is required for the device. This approach may require either
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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-sip-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 PIDF-LO document (by value) and indirectly directly in the form of a Presence Information Data Format Location
as a Location URI (by reference). The security necessary to ensure Object (PIDF-LO) document (by value) and indirectly as a Location URI
the accuracy, privacy and confidentiality of the device's location is (by reference). The security necessary to ensure the accuracy,
described in the Security Considerations (Section 9). privacy and confidentiality of the device's location is 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 to be an https: URI. provided by LIS discovery is RECOMMENDED to be an https: URI.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
dependent. dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element MAY be included in a location request The "locationType" element MAY be included in a location request
message. It contains a list of LI types that are requested by the message. It contains a list of LI types that are requested by the
Device. The following list describes the possible values: Device. The following list describes the possible values:
any: The LIS SHOULD attempt to provide LI in all forms available to any: The LIS SHOULD attempt to provide LI in all forms available to
it. it.
geodetic: The LIS SHOULD return a geodetic location for the Target. geodetic: The LIS SHOULD return a location by value in the form of a
civic: The LIS SHOULD return a civic address for the Target. geodetic location for the Target.
civic: The LIS SHOULD return a location by value in the form of a
civic address for the Target.
locationURI: The LIS SHOULD return a set of location URIs for the locationURI: The LIS SHOULD return a set of location URIs for the
Target. Target.
The LIS SHOULD return the requested location type or types. The The LIS SHOULD return the requested location type or types. The
location types the LIS returns also depend on the setting of the location types the LIS returns also depend on the setting of the
optional "exact" attribute. If the "exact" attribute is set to optional "exact" attribute. If the "exact" attribute is set to
"true" then the LIS MUST return either the requested location type or "true" then the LIS MUST return either the requested location type or
provide an error response. The "exact" attribute does not apply (is provide an error response. The "exact" attribute does not apply (is
ignored) for a request for a location type of "any". Further detail ignored) for a request for a location type of "any". Further detail
of the "exact" attribute processing is provided in the following of the "exact" attribute processing is provided in the following
skipping to change at page 16, line 34 skipping to change at page 16, line 34
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
requested. The LIS MUST follow the subset of the rules relating to requested. The LIS MUST follow the subset of the rules relating to
the construction of the "location-info" element in the PIDF-LO Usage the construction of the "location-info" element in the PIDF-LO Usage
Clarification, Considerations and Recommendations document [RFC5491] Clarification, Considerations and Recommendations document [RFC5491]
in generating the PIDF-LO for the presence parameter. in generating the PIDF-LO for the presence parameter.
The LIS MUST NOT include any means of identifying the Device in the
PIDF-LO unless it is able to verify that the identifier is correct
and inclusion of identity is expressly permitted by a Rule Maker.
Therefore, PIDF parameters that contain identity are either omitted
or contain unlinked pseudonyms [RFC3693]. A unique, unlinked
presentity URI SHOULD be generated by the LIS for the mandatory
presence "entity" attribute of the PIDF document. Optional
parameters such as the "contact" element and the "deviceID" element
[RFC4479] are not used.
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
This section gives the XML Schema Definition This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the [W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
skipping to change at page 20, line 37 skipping to change at page 21, line 7
This section describes the use of HTTP [RFC2616] and HTTP Over TLS This section describes the use of HTTP [RFC2616] and HTTP Over TLS
[RFC2818] as transport mechanisms for the HELD protocol, which a [RFC2818] as transport mechanisms for the HELD protocol, which a
conforming LIS and Device MUST support. conforming LIS and Device MUST support.
Although HELD uses HTTP as a transport, it uses a strict subset of Although HELD uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a LIS is HTTP features, and due to the restrictions of some features, a LIS is
not a fully compliant HTTP server. It is intended that a LIS can not a fully compliant HTTP server. It is intended that a LIS can
easily be built using an HTTP server with extensibility mechanisms, easily be built using an HTTP server with extensibility mechanisms,
and that a HELD Device can trivially use existing HTTP libraries. and that a HELD Device can trivially use existing HTTP libraries.
This subset of requirements helps implementors avoid ambiguity with This subset of requirements helps implementors avoid ambiguity with
the many options the full HTTP protocol offers. The LIS MUST NOT the many options the full HTTP protocol offers.
rely on device support for cookies [RFC2965] or use Basic or Digest
authentication [RFC2617]. A Device that conforms to this specification MAY choose not to
support HTTP authentication [RFC2617] or cookies [RFC2965]. Because
the Device and the LIS may not necessarily have a prior relationship,
the LIS SHOULD NOT require a Device to authenticate, either using the
above HTTP authentication methods or TLS client authentication.
Unless all Devices that access a LIS can be expected to be able to
authenticate in a certain fashion, denying access to location
information could prevent a Device from using location-dependent
services, such as emergency calling.
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 24, line 11 skipping to change at page 24, line 37
the response to this IP address will provide sufficient assurance in the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that many cases. This is the default mechanism in HELD for assuring that
location is given only to authorized clients; LIS implementations location is given only to authorized clients; LIS implementations
MUST support a mode of operation in which this is the only client MUST support a mode of operation in which this is the only client
authentication. authentication.
Using IP return routability as an authenticator means that location Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of IP address could mean that a device attacks. A temporary spoofing of IP address could mean that a device
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 receiving another Device's location if the attacker is able to
drops off the network for various reasons, the re-use of the Device's receive packets sent to the spoofed address. In addition, in cases
IP address could result in another Device receiving the original where a Device drops off the network for various reasons, the re-use
Device's location rather than its own location. These exposures are of the Device's IP address could result in another Device receiving
limited by the following: the original Device's location rather than its own location. These
exposures are 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 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.
skipping to change at page 32, line 49 skipping to change at page 32, line 49
of the original document, from which this WG document was derived. of the original document, from which this WG document was derived.
Their contact information is included in the Author's address Their contact information is included in the Author's address
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,
Eric Arolick, Richard Barnes (in particular the security section), Bernard Aboba, Eric Arolick, Richard Barnes (in particular the
Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin security section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy
Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Corbett, Martin Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie,
Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Cullen Jennings, Neil Justusson, Tat Lam, Marc Linsner, Patti
Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, Julian
Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Reschke, Eric Rescorla, Brian Rosen, John Schnizlein, Shida Schubert,
Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. Henning 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 14 to 15(Gen-Art and IETF discussion ML comments post
3rd IETF LC):
1) Clarification around device support for cookies or basic/digest
authentication.
2)Additional text in section 6.3 (PIDF-LO) around the LIS including
(and not including) any information identifying the device in the
returned PIDF-LO.
3) As always, a few additional editorial changes and clarifications.
Changes from 13 to 14 (AD comments post 2nd IETF LC): Changes from 13 to 14 (AD comments post 2nd IETF LC):
1) Section 4.3: Removed reference to location-dereference protocol 1) Section 4.3: Removed reference to location-dereference protocol
document. Generalized statement wrt HELD not meeting all the lbyr document. Generalized statement wrt HELD not meeting all the lbyr
requirements (e.g., cancelling of location references). requirements (e.g., cancelling of location references).
2) Removed section 5.1 (Delivery Protocol) and just left the 2) Removed section 5.1 (Delivery Protocol) and just left the
statement that this document describes the use of HTTP and that HELD statement that this document describes the use of HTTP and that HELD
is an application layer protocol. is an application layer protocol.
skipping to change at page 40, line 40 skipping to change at page 41, line 4
[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]
Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, Thompson, H., Mendelsohn, N., Maloney, M., 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 39 skipping to change at page 41, line 50
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.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
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-09 (work in
progress), February 2009. progress), February 2009.
 End of changes. 20 change blocks. 
40 lines changed or deleted 80 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/