draft-ietf-geopriv-http-location-delivery-13.txt   draft-ietf-geopriv-http-location-delivery-14.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: August 29, 2009 Expires: November 12, 2009
February 25, 2009 May 11, 2009
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-13.txt draft-ietf-geopriv-http-location-delivery-14.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 August 29, 2009. This Internet-Draft will expire on November 12, 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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10 5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 10
5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.2. Location Response . . . . . . . . . . . . . . . . . . . . 10
5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring that the proper LIS has been contacted . . . . . 23 9.1. Assuring that the proper LIS has been contacted . . . . . 22
9.2. Protecting responses from modification . . . . . . . . . . 24 9.2. Protecting responses from modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . . 40
15.2. Informative References . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 42
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 42 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 42
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 43
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 43
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 44
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 44 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 44
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 45
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 8, line 51 skipping to change at page 8, line 51
4.2. Location by Value 4.2. Location by Value
Where a Device requires LI directly, it can request that the LIS Where a Device requires LI directly, it can request that the LIS
create a PIDF-LO document. This approach fits well with a create a PIDF-LO document. This approach fits well with a
configuration whereby the device directly makes use of the provided configuration whereby the device directly makes use of the provided
PIDF-LO document. The details on the information that may be PIDF-LO document. The details on the information that may be
included in the PIDF-LO MUST follow the subset of those rules included in the PIDF-LO MUST follow the subset of those rules
relating to the construction of the "location-info" element in the relating to the construction of the "location-info" element in the
PIDF-LO Usage Clarification, Considerations and Recommendations PIDF-LO Usage Clarification, Considerations and Recommendations
document [I-D.ietf-geopriv-pdif-lo-profile]. Further detail is document [RFC5491]. Further detail is included in the detailed
included in the detailed protocol section of this document Section 6 protocol section of this document Section 6
4.3. Location by Reference 4.3. Location by Reference
Requesting location directly does not always address the requirements Requesting location directly does not always address the requirements
of an application. A Device can request a location URI instead of of an application. A Device can request a location URI instead of
literal location. A Location URI is a URI [RFC3986] of any scheme, literal location. A Location URI is a URI [RFC3986] of any scheme,
which a Location Recipient (LR) can use to retrieve LI. A location which a Location Recipient (LR) can use to retrieve LI. A location
URI provided by a LIS can be assumed to be globally-addressable; that URI provided by a LIS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LIS. is, anyone in possession of the URI can access the LIS.
However, possession of the URI does not in any way suggest that the However, possession of the URI does not in any way suggest that the
LIS indiscriminately reveals the location associated with the LIS indiscriminately reveals the location associated with the
location URI. The specific requirements associated with the location URI. The specific requirements associated with the
dereference of the location are specified in dereference of the location are specified in
[I-D.ietf-geopriv-lbyr-requirements]. The location dereference [I-D.ietf-geopriv-lbyr-requirements]. The location dereference
protocol details are out of scope of this document and are specified protocol details are out of scope of this document. As such, many of
in [I-D.winterbottom-geopriv-deref-protocol]. the requirements in [I-D.ietf-geopriv-lbyr-requirements] (e.g.,
cancelling of location references) are not intended to be supported
It should also be noted that while the lybr requirements document by this specification. It is anticipated that future specifications
specifies a requirement that a client SHOULD be able to cancel may address these requirements.
location references, the protocol specified in this document does not
provide that functionality. The mechanism to provide this support in
the protocol requires explicit management of Target state on the LIS.
It is anticipated that extensions to HELD may support that
requirement.
5. Protocol Description 5. Protocol Description
As discussed in Section 4, this protocol provides for the retrieval As discussed in Section 4 the HELD protocol provides for the
of the device's location in the form of a PIDF-LO document and/or retrieval of the device's location in the form of a PIDF-LO document
Location URI(s) from a LIS. Three messages are defined to support and/or Location URI(s) from a LIS. Three messages are defined to
the location retrieval: locationRequest, locationResponse and error. support the location retrieval: locationRequest, locationResponse and
Messages are defined as XML documents. error. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 5.2. A Location Request message from a Device indicates Section 5.1. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific whether location in the form of a PIDF-LO document (with specific
type(s) of location) and/or Location URI(s) should be returned. The type(s) of location) and/or Location URI(s) should be returned. The
LIS replies with a locationResponse message, including a PIDF-LO LIS replies with a locationResponse message, including a PIDF-LO
document and/or one or more Location URIs in case of success. In the document and/or one or more Location URIs in case of success. In the
case of an error, the LIS replies with an error message. case of an error, the LIS replies with an error message.
A MIME type "application/held+xml" is registered in Section 11.3 to A MIME type "application/held+xml" is registered in Section 11.3 to
distinguish HELD messages from other XML document bodies. This distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described specification follows the recommendations and conventions described
in [RFC3023], including the naming convention of the type ('+xml' in [RFC3023], including the naming convention of the type ('+xml'
suffix) and the usage of the 'charset' parameter. suffix) and the usage of the 'charset' parameter.
Section 6 contains a more thorough description of the protocol Section 6 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 7 parameters, valid values, and how each should be handled. Section 7
contains a more specific definition of the structure of these contains a more specific definition of the structure of these
messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028]. messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
5.1. Delivery Protocol
The HELD protocol is an application-layer protocol specified by an
XML document. The HELD protocol is defined independently of any
lower layers used to transport messages from one host to another.
This means that any protocol can be used to transport this protocol
providing that it can provide a few basic features:
o The HELD protocol doesn't provide any mechanisms that enable
detection of missing messages and retransmission, thus the
protocol must have acknowledged delivery.
o The HELD protocol is a request/response protocol, thus the
protocol must be able to correlate a response with a request.
o The HELD protocol RECOMMENDS that the underlying transport provide
authentication, confidentiality, and protection against
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 [RFC5246] and TCP [RFC0793] in Section 8. TLS [RFC5246] and TCP [RFC0793] in Section 8.
5.2. Location Request 5.1. 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
location request message as the primary source of identity for the location request message as the primary source of identity for the
requesting device or target. It is anticipated that other Device requesting device or target. It is anticipated that other Device
identities may be provided through schema extensions. identities may be provided through schema extensions.
The LIS MUST ignore any part of a location request message that it The LIS MUST ignore any part of a location request message that it
does not understand, except the document element. does not understand, except the document element.
5.3. Location Response 5.2. Location Response
A successful response to a location request MUST contain a PIDF-LO A successful response to a location request MUST contain a PIDF-LO
and/or location URI(s). The response SHOULD contain location and/or location URI(s). The response SHOULD contain location
information of the requested "locationType". The cases whereby a information of the requested "locationType". The cases whereby a
different type of location information MAY be returned are described different type of location information MAY be returned are described
in Section 6.2. in Section 6.2.
5.4. Indicating Errors 5.3. Indicating Errors
If the LIS is unable to provide location information based on the If the LIS is unable to provide location information based on the
received locationRequest message, it MUST return an error message. received locationRequest message, it MUST return an error message.
The LIS may return an error message in response to requests for any The LIS may return an error message in response to requests for any
"locationType". "locationType".
An error indication document consists of an "error" element. The An error indication document consists of an "error" element. The
"error" element MUST include a "code" attribute that indicates the "error" element MUST include a "code" attribute that indicates the
type of error. A set of predefined error codes are included in type of error. A set of predefined error codes are included in
Section 6.3. Section 6.3.
skipping to change at page 12, line 23 skipping to change at page 11, line 51
could be either for routing a call to the appropriate PSAP or could be either for routing a call to the appropriate PSAP or
indicating the location to which responders should be dispatched. indicating the location to which responders should be dispatched.
The values defined for the purpose, "emergencyRouting" and The values defined for the purpose, "emergencyRouting" and
"emergencyDispatch", will likely be governed by jurisdictional "emergencyDispatch", will likely be governed by jurisdictional
policies, and should be configurable on the LIS. policies, and should be configurable on the LIS.
The time value in the "responseTime" attribute is expressed as a non- The time value in the "responseTime" attribute is expressed as a non-
negative integer in units of milliseconds. The time value is negative integer in units of milliseconds. The time value is
indicative only and the LIS is under no obligation to strictly adhere indicative only and the LIS is under no obligation to strictly adhere
to the time limit implied; any enforcement of the time limit is left to the time limit implied; any enforcement of the time limit is left
to the requesting Device. The LIS should provide the most accurate to the requesting Device. The LIS provides the most accurate LI that
LI that can be determined within the specified interval for the can be determined within the specified interval for the specific
specific service. service.
The LIS may use the value of the time in the "responseTime" attribute The LIS may use the value of the time in the "responseTime" attribute
as input when selecting the method of location determination, where as input when selecting the method of location determination, where
multiple such methods exist. If the "responseTime" attribute is multiple such methods exist. If the "responseTime" attribute is
absent, then the LIS should return the most precise LI it is capable absent, then the LIS should return the most precise LI it is capable
of determining, with the time interval being implementation of determining, with the time interval being implementation
dependent. dependent.
6.2. "locationType" Parameter 6.2. "locationType" Parameter
skipping to change at page 14, line 32 skipping to change at page 14, line 10
the requested type or types or MUST provide an error. The LIS MUST the requested type or types or MUST provide an error. The LIS MUST
provide the requested types only. The LIS MUST handle an exact provide the requested types only. The LIS MUST handle an exact
request that includes a "locationType" element set to "any" as if the request that includes a "locationType" element set to "any" as if the
"exact" attribute were set to "false". "exact" attribute were set to "false".
6.3. "code" Parameter 6.3. "code" Parameter
All "error" responses MUST contain a response code. All errors are All "error" responses MUST contain a response code. All errors are
application-level errors, and MUST only be provided in successfully application-level errors, and MUST only be provided in successfully
processed transport-level responses. For example where HTTP/HTTPS is processed transport-level responses. For example where HTTP/HTTPS is
used as the transport, HELD error messages MUST be accompanied by a used as the transport, HELD error messages MUST be carried by a 200
200 OK HTTP/HTTPS response. OK HTTP/HTTPS response.
The value of the response code MUST be one of the following tokens: The value of the response code MUST be one of the following tokens:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion (other than the XML content). in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
was either badly formed or invalid. was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LIS. occurred at the LIS.
locationUnknown: This code indicates that the LIS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device. The same request can be
sent by the Device at a later time. Devices MUST limit any
attempts to retry requests.
unsupportedMessage: This code indicates that an element in the XML unsupportedMessage: This code indicates that an element in the XML
document for the request, was not supported or understood by the document for the request, was not supported or understood by the
LIS. This error code is used when a HELD request contains a LIS. This error code is used when a HELD request contains a
document element that is not supported by the receiver. document element that is not supported by the receiver.
timeout: This code indicates that the LIS could not satisfy the timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter. request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to the Device, and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS;
skipping to change at page 15, line 20 skipping to change at page 14, line 44
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to the Device, and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in for instance, the VPN and NAT scenarios discussed in
Section 4.1.2. Section 4.1.2.
6.4. "message" Parameter 6.4. "message" Parameter
The "error" message MAY include a "message" attribute to convey some The "error" message MAY include one or more "message" attributes to
additional, human-readable information about the result of the convey some additional, human-readable information about the result
request. This message MAY be included in any language, which SHOULD of the request. The message MAY be included in any language, which
be indicated by the "xml:lang", attribute. The default language is SHOULD be indicated by the "xml:lang", attribute. The default
assumed to be English. language is assumed to be English.
6.5. "locationUriSet" Parameter 6.5. "locationUriSet" Parameter
The "locationUriSet" element, received in a "locationResponse" The "locationUriSet" element, received in a "locationResponse"
message MAY contain any number of "locationURI" elements. It is message MAY contain any number of "locationURI" elements. It is
RECOMMENDED that the LIS allocate a Location URI for each scheme that RECOMMENDED that the LIS allocate a Location URI for each scheme that
it supports and that each scheme is present only once. URI schemes it supports and that each scheme is present only once. URI schemes
and their secure variants, such as http and https, MUST be regarded and their secure variants, such as http and https, MUST be regarded
as two separate schemes. as two separate schemes.
skipping to change at page 17, line 4 skipping to change at page 16, line 31
dereferences a location URI after the expiry time, the dereference dereferences a location URI after the expiry time, the dereference
SHOULD fail. SHOULD fail.
6.6. "Presence" Parameter (PIDF-LO) 6.6. "Presence" Parameter (PIDF-LO)
A single "presence" parameter MAY be included in the A single "presence" parameter MAY be included in the
"locationResponse" message when specific locationTypes (e.g., "locationResponse" message when specific locationTypes (e.g.,
"geodetic" or "civic") are requested or a "locationType" of "any" is "geodetic" or "civic") are requested or a "locationType" of "any" is
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 Clarification, Considerations and Recommendations document [RFC5491]
[I-D.ietf-geopriv-pdif-lo-profile] in generating the PIDF-LO for the 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
This section gives the XML Schema Definition This section gives the XML Schema Definition
skipping to change at page 17, line 44 skipping to change at page 17, line 22
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This document (RFC xxxx) defines HELD messages. This document (RFC xxxx) defines HELD messages.
<!-- [[NOTE TO RFC-EDITOR: Please replace XXXX <!-- [[NOTE TO RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]] --> with the RFC number for this specification.]] -->
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Return Location --> <!-- Return Location -->
<xs:complexType name="returnLocationType"> <xs:complexType name="returnLocationType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationURI" type="xs:anyURI" <xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="expires" type="xs:dateTime" <xs:attribute name="expires" type="xs:dateTime"
skipping to change at page 18, line 34 skipping to change at page 18, line 7
</xs:simpleType> </xs:simpleType>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:union> </xs:union>
</xs:simpleType> </xs:simpleType>
<!-- Location Type --> <!-- Location Type -->
<!-- Location Type -->
<xs:simpleType name="locationTypeBase"> <xs:simpleType name="locationTypeBase">
<xs:union> <xs:union>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="any"/> <xs:enumeration value="any"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="held:locationTypeList"> <xs:restriction base="held:locationTypeList">
<xs:minLength value="1"/> <xs:minLength value="1"/>
skipping to change at page 19, line 39 skipping to change at page 19, line 11
use="optional"/> use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="errorType"> <xs:complexType name="errorType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="message" type="held:errorMsgType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="code" type="xs:token" <xs:attribute name="code" type="xs:token"
use="required"/> use="required"/>
<xs:attribute name="message" type="xs:string"
use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="errorMsgType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="error" type="held:errorType"/> <xs:element name="error" type="held:errorType"/>
<!-- Location Response --> <!-- Location Response -->
<xs:complexType name="locationResponseType"> <xs:complexType name="locationResponseType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="locationUriSet" <xs:element name="locationUriSet"
type="held:returnLocationType" type="held:returnLocationType"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationResponse" <xs:element name="locationResponse"
type="held:locationResponseType"/> type="held:locationResponseType"/>
<!-- Location Request --> <!-- Location Request -->
<xs:complexType name="locationRequestType"> <xs:complexType name="locationRequestType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="held:baseRequestType"> <xs:extension base="held:baseRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="locationType" <xs:element name="locationType"
type="held:locationTypeType" type="held:locationTypeType"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
skipping to change at page 22, line 14 skipping to change at page 21, line 37
the LI. This also allows the LIS to control any caching with the the LI. This also allows the LIS to control any caching with the
HELD "expires" parameter. The HTTP status code MUST indicate a 2xx HELD "expires" parameter. The HTTP status code MUST indicate a 2xx
series response for all HELD locationResponse and HELD error series response for all HELD locationResponse and HELD error
messages. messages.
The LIS MAY redirect a HELD request. A Device MUST handle redirects, The LIS MAY redirect a HELD request. A Device MUST handle redirects,
by using the Location header provided by the server in a 3xx by using the Location header provided by the server in a 3xx
response. When redirecting, the Device MUST observe the delay response. When redirecting, the Device MUST observe the delay
indicated by the Retry-After header. The Device MUST authenticate indicated by the Retry-After header. The Device MUST authenticate
the server that returns the redirect response before following the the server that returns the redirect response before following the
redirect. A Device SHOULD authenticate the LIS indicated in a redirect, if a Device requires that the server is authenticated. A
redirect. Device SHOULD authenticate the LIS indicated in a redirect.
The LIS SHOULD support persistent connections and request pipelining. The LIS SHOULD support persistent connections and request pipelining.
If pipelining is not supported, the LIS MUST NOT allow persistent If pipelining is not supported, the LIS MUST NOT allow persistent
connections. The Device MUST support termination of a response by connections. The Device MUST support termination of a response by
the closing of a connection. the closing of a connection.
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 Implementations of HELD that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between Device and LIS. The Device MUST implement confidentiality between Device and LIS. The Device MUST implement
the server authentication method described in HTTPS [RFC2818]. The the server authentication method described in HTTPS [RFC2818]. The
device uses the URI obtained during LIS discovery to authenticate the device uses the URI obtained during LIS discovery to authenticate the
server. The details of this authentication method are provided in server. The details of this authentication method are provided in
section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD 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 fail a request if server authentication fails, except in the event of
an emergency. an emergency.
skipping to change at page 26, line 30 skipping to change at page 26, line 30
entity="pres:3650n87934c@ls.example.com"> entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd"> <tuple id="b650sf789nd">
<status> <status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"> <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info> <location-info>
<Point xmlns="http://www.opengis.net/gml" <Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326"> srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos> <pos>-34.407 150.88001</pos>
</Point> </Point>
</location-info> </location-info>
<usage-rules> <usage-rules
<retention-expiry> xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
2006-01-11T03:42:28+00:00</retention-expiry> <gbp:retention-expiry>2006-01-11T03:42:28+00:00
</gbp:retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
The error response to the request is an error document. The The error response to the request is an error document. The
following response shows an example error response. following response shows an example error response.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
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 xml:lang="en">Unable to determine location
</message>
</error>
10.2. Simple Location Request Example 10.2. Simple Location Request Example
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of The example response to this location request contains a list of
Location URIs. Location URIs.
skipping to change at page 28, line 7 skipping to change at page 28, line 7
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"/>
message="Location not available"/> <message="Location not available"
</message>
</error>
10.3. Location Request Example for Multiple Location Types 10.3. Location Request Example for Multiple Location Types
The following Location Request message includes a request for The following Location Request message includes a request for
geodetic, civic and any Location URIs. geodetic, civic and any Location URIs.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true"> <locationType exact="true">
geodetic geodetic
civic civic
skipping to change at page 28, line 33 skipping to change at page 28, line 35
The corresponding Location Response message includes the requested The corresponding Location Response message includes the requested
location information, including two location URIs. location information, including two location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv> <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info> <location-info>
<gs:Circle <gs:Circle xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326"> srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos> <gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
<ca:civicAddress <ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au"> xml:lang="en-au">
<ca:country>AU</ca:country> <ca:country>AU</ca:country>
skipping to change at page 29, line 22 skipping to change at page 29, line 24
<ca:STS>Northfield Avenue</ca:STS> <ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK> <ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR> <ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM> <ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC> <ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD> <ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT> <ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX> <ca:POBOX>U40</ca:POBOX>
</ca:civicAddress> </ca:civicAddress>
</location-info> </location-info>
<usage-rules> <usage-rules
<retransmission-allowed>false</retransmission-allowed> xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<retention-expiry>2007-05-25T12:35:02+10:00 <gbp:retransmission-allowed>false
</retention-expiry> </gbp:retransmission-allowed>
<gbp:retention-expiry>2007-05-25T12:35:02+10:00
</gbp:retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp> <timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
11. IANA Considerations 11. IANA Considerations
skipping to change at page 31, line 45 skipping to change at page 31, line 48
Section 6.3 and defined in the schema in the 'codeType' token in the Section 6.3 and defined in the schema in the 'codeType' token in the
XML schema in (Section 7) XML schema in (Section 7)
The following summarizes the requested registry: The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
Registration/Assignment Procedures: Following the policies outlined Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the in [RFC5226], the IANA policy for assigning new values for the
Error codes for HELD shall be Specification Required: values and Error codes for HELD shall be Standards Action: Values are
their meanings must be documented in an RFC or in some other assigned only for Standards Track RFCs approved by the IESG.
permanent and readily available reference, in sufficient detail
that interoperability between independent implementations is
possible.
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
This section pre-registers the following seven initial error codes as This section pre-registers the following seven initial error codes as
described above in Section 6.3: described above in Section 6.3:
requestError: This code indicates that the request was badly formed requestError: This code indicates that the request was badly formed
in some fashion. in some fashion.
xmlError: This code indicates that the XML content of the request xmlError: This code indicates that the XML content of the request
skipping to change at page 33, 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 13 to 14 (AD comments post 2nd IETF LC):
1) Section 4.3: Removed reference to location-dereference protocol
document. Generalized statement wrt HELD not meeting all the lbyr
requirements (e.g., cancelling of location references).
2) Removed section 5.1 (Delivery Protocol) and just left the
statement that this document describes the use of HTTP and that HELD
is an application layer protocol.
3) Section 6.1: "the LIS should provide the most accurate LI" -> "the
LIS provides the most accurate LI" to avoid the inference of a
normative requirement.
4) Section 6.3: clarified "locationUnknown" error code.
5) Section 6.4: changed text to indication that errors can contain
multiple "message" parameters to accommodate errors in different
languages.
6) Section 7 : updated XML schema to reflect change in error message
to accommodate multiple "message" parameters. Note, a few other
changes to XML schema based on "strict" validation.
7) Section 8: clarified that redirect should be authenticated if the
Device requires that the redirect server is authenticated.
8) Section 10:
- updated examples due to updates to XML schema
- removed empty POST example.
9) Section 11.4: Changed IANA registration for error codes from
"Specification Required" to "Standards Action"
10) Other minor clarifications.
Changes from WG 12 to 13 (Post-2nd WGLC): Changes from WG 12 to 13 (Post-2nd WGLC):
1) Fixed editorial error in section 6.2 with regards to empty 1) Fixed editorial error in section 6.2 with regards to empty
"locationType" - error was introduced in 06 to 07 changes. "locationType" - error was introduced in 06 to 07 changes.
2) Added additional text in section 6.5.1 to improve security 2) Added additional text in section 6.5.1 to improve security
associated with locationURIs. associated with locationURIs.
3) Modified XML schema for errorType and responseType to allow an 3) Modified XML schema for errorType and responseType to allow an
attribute to be returned. Also, added extensibility to errorType. attribute to be returned. Also, added extensibility to errorType.
skipping to change at page 39, line 40 skipping to change at page 40, line 29
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. 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] [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
PIDF-LO Usage Clarification, Considerations and Usage Clarification, Considerations, and Recommendations",
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 RFC 5491, March 2009.
(work in progress), November 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, Beech, D., Thompson, H., Mendelsohn, N., 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 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>.
[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-07 (work in progress), draft-ietf-geopriv-lis-discovery-11 (work in progress),
February 2009. May 2009.
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.
[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.
[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
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
skipping to change at page 41, line 15 skipping to change at page 41, line 51
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.
[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-06 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work
in progress), February 2009. in progress), February 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-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-12 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
November 2008. March 2009.
[I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-03 (work in
progress), February 2009.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in the [I-D.ietf-geopriv-l7-lcp-ps].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the define an identifier that is mandatory to implement. Regarding the
skipping to change at page 44, line 48 skipping to change at page 45, line 34
HELD uses the discovery mechanism in HELD uses the discovery mechanism in
[I-D.ietf-geopriv-lis-discovery]. [I-D.ietf-geopriv-lis-discovery].
A.10. L7-10: PIDF-LO Creation A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
<geopriv> element into the <device> element of the presence document <geopriv> element into the <device> element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document, (see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the which is subsequently distributed to other entities, conforms to the
rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile] rules outlined in ". [RFC5491]
COMPLY COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile]. by the LIS MUST conform to [RFC5491].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
USA USA
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
 End of changes. 56 change blocks. 
144 lines changed or deleted 153 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/