draft-ietf-geopriv-http-location-delivery-00.txt   draft-ietf-geopriv-http-location-delivery-01.txt 
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: December 9, 2007 Expires: January 10, 2008
June 7, 2007 July 9, 2007
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-00.txt draft-ietf-geopriv-http-location-delivery-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9 6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9
6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 9 6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
6.3. Held Response . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11 7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
7.2.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 12 7.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
7.3. "options" Parameter . . . . . . . . . . . . . . . . . . . 13 7.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
7.4. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 7.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
7.5. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 7.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14
7.6. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14 7.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14
7.6.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 18 9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20
10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21 11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21
11.2. Simple Location Request Example . . . . . . . . . . . . . 24 11.2. Simple Location Request Example . . . . . . . . . . . . . 24
11.3. Location Request Example with options . . . . . . . . . . 25 11.3. Location Request Example for Multiple Location Types . . . 25
11.4. Location Request Example for Multiple Location Types . . . 27 11.4. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 26
11.5. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 12.1. URN Sub-Namespace Registration for
12.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 29 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27
12.2. IANA Registry for HELD Location Request Options . . . . . 30 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27
12.3. URN Sub-Namespace Registration for 12.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30 urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 27
12.4. XML Schema Registration . . . . . . . . . . . . . . . . . 31 12.4. MIME Media Type Registration for 'application/held+xml' . 28
12.5. URN Sub-Namespace Registration for 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
12.6. MIME Media Type Registration for 'application/held+xml' . 32 15. Changes since last Version . . . . . . . . . . . . . . . . . . 29
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 35 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 33
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 35 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 33
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 33
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 34
A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 36 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 34
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 35
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 35
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 37 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 35
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 35
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40
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 LCP problem statement and requirements of applications. The L7 LCP problem statement and requirements
document [11] provides some scenarios in which a Device might rely on document [11] provides some scenarios in which a Device might rely on
its access network to provide the location information, such as such its access network to provide the location information, such as such
as fixed environments (e.g., DSL/Cable), mobile networks and wireless as fixed environments (e.g., DSL/Cable), mobile networks and wireless
access networks. This document describes a protocol that can be used access networks. This document describes a protocol that can be used
to acquire Location Information (LI) from a service within an access to acquire Location Information (LI) from a service within an access
network. The service within an access network is assumed to be network. The service within an access network is assumed to be
provided by a Location Configuration Server (LCS), as introduced in provided by a Location Configuration Server (LCS), as introduced in
the L7 LCP problem statement and requirements document. the L7 LCP problem statement and requirements document.
This specification identifies two methods for acquiring LI. Location This specification identifies two methods for acquiring LI. Location
may be retrieved from a Location Configuration Server (LCS) by-value, may be retrieved from a Location Configuration Server (LCS) by-value,
that is, the Device may acquire LI directly. Alternatively, the that is, the Device may acquire a literal location object describing
Device may request that the LCS provide a location URI so that LI can the location of the Device. Alternatively, the Device may request
be distributed by-reference. Both of these methods are compatible, that the LCS provide a location reference in the form of a location
and both can be provided concurrently from the same LCS so that URI or set of location URIs, allowing the Device to distribute its LI
application needs can be addressed individually. by-reference. Both of these methods are compatible, and both can be
provided concurrently from the same LCS so that application needs can
be addressed individually.
This specification defines an XML-based protocol that enables the This specification defines an XML-based protocol that enables the
retrieval of LI from a LCS by a Device. This protocol can be bound retrieval of LI from a LCS by a Device. This protocol can be bound
to any session-layer protocol, particularly those capable of MIME to any session-layer protocol, particularly those capable of MIME
transport; an HTTP binding is included as a minimum requirement. transport; an HTTP binding is included as a minimum requirement.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 32 skipping to change at page 5, line 35
for jurisdictional (general use) or postal (message delivery) for jurisdictional (general use) or postal (message delivery)
purposes, or they can apply to either. purposes, or they can apply to either.
Device: The technical device whereby the location is tracked as a Device: The technical device whereby the location is tracked as a
proxy for the location of a Target. proxy for the location of a Target.
Geodetic Location: A location expressed in coordinate form. Geodetic Location: A location expressed in coordinate form.
Location Configuration Server (LCS): The entity within the Access Location Configuration Server (LCS): The entity within the Access
Provider's network that provides location information to clients. Provider's network that provides location information to clients.
This term is introduced in [11] and it provides the location This term is introduced in [11] and refers to an entity capable of
information that is generated and maintained by the LG and LS determining the location of an end point and providing that
functional elements respectively. The details of the interactions location information via the Location Configuration Protocol (LCP)
between an LG and LS and in particular how the LCS uses these to to the requesting party. The requesting party is the end point
obtain location information is outside the scope of this document itself or an authorized entity that acts on its behalf.
since it is very deployment specific.
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location Objects gathers the location of the Target and creates Location Objects
describing that location. describing that location.
Location Information (LI): The data that describes the location of a Location Information (LI): The data that describes the location of a
Device. The term LI does not include the representation of this Device, either by-value or by-reference. The term LI does not
data. include the representation of this data.
Note: this terms is not officially defined in [7], but rather is Note: this terms is not officially defined in [7], but rather is
assumed from the general usage throughout that document and within assumed from the general usage throughout that document and within
the GEOPRIV WG. the GEOPRIV WG.
Location Object (LO): An object conveying Location Information (and Location Object (LO): An object conveying Location Information (and
possibly privacy rules) to which Geopriv security mechanisms and possibly privacy rules) to which Geopriv security mechanisms and
privacy rules are to be applied. privacy rules are to be applied.
Note: this is a specific by-value representation of Location Note: this is a specific by-value representation of Location
Information (LI). In this document, LO refers to PIDF-LO [8]. Information (LI). In this document, LO refers to PIDF-LO [8].
skipping to change at page 6, line 49 skipping to change at page 6, line 49
This document describes an interface between a Device and a Location This document describes an interface between a Device and a Location
Configuration Server (LCS). The LCS is a service present within the Configuration Server (LCS). The LCS is a service present within the
same administrative domain as the Device (the access network). An same administrative domain as the Device (the access network). An
Access Provider (AP) operates the LCS service so that Devices (and Access Provider (AP) operates the LCS service so that Devices (and
Targets) can retrieve LI. The LCS exists because not all Devices are Targets) can retrieve LI. The LCS exists because not all Devices are
capable of determining LI, and because, even if a device is able to capable of determining LI, and because, even if a device is able to
determine its own LI, it may be more efficient with assistance. This determine its own LI, it may be more efficient with assistance. This
document does not specify how LI is derived. document does not specify how LI is derived.
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
some additional assurances about the link between device and target, some additional assurances about the link between device and target,
or an acceptance of the limitation that unless the device requires or an acceptance of the limitation that unless the device requires
active user authentication, there is no guarantee that any particular active user authentication, there is no guarantee that any particular
individual is using the device at that instant. individual is using the device at that instant.
This document identifies two methods for acquiring LI. Location may This document identifies two methods for acquiring LI. Location may
be retrieved from a Location Configuration Server (LCS) by-value, be retrieved from a Location Configuration Server (LCS) by-value,
that is, the device may acquire LI directly. Alternatively, the that is, the Device may acquire a literal location in ther form of a
Device may request that the LCS provide a location URI so that LI can PIDF-LO. Alternatively, the Device may request that the LCS provide
be distributed by-reference. Providing LI by-reference implies that a location reference in the form of a location URI or set of location
a server is able to provide the device with a public, globally- URIs, allowing the Device to distribute its LI by-reference.
addressable URI. Providing LI by-reference implies that a server is able to provide
the Device with a public, globally-addressable URI.
The following diagram shows the logical configuration of some of the The following diagram shows the logical configuration of some of the
functional elements identified in [7] and the LCS defined in [11] and functional elements identified in [7] and the LCS defined in [11] and
where this protocol applies, with the Rule Maker and Target where this protocol applies, with the Rule Maker and Target
represented by the role of the Device. represented by the role of the Device.
+---------------------------------------------+ +---------------------------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +--------------------------------------+ | | +--------------------------------------+ |
skipping to change at page 8, line 15 skipping to change at page 8, line 17
and/or LCS is application specific, as indicated by the APP and/or LCS 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 [24]. be found in the SIP Location Conveyance document [24].
5. Protocol Overview 5. Protocol Overview
The HELD protocol facilitates retrieval of LI either by-value, as a The HELD protocol facilitates retrieval of LI either by-value, as a
PIDF-LO document, or by-reference, as a Location URI. The policy PIDF-LO document, or by-reference, as a Location URI. The policy
that describes to whom, and how, LI is granted is outside the scope that describes to whom, and how, LI is granted is outside the scope
of this document and and maybe specified in separate specifications of this document and MAY be specified in separate specifications as
as required. The Device must first discover the URI for the LCS for required. The Device must first discover the URI for the LCS for
sending the HELD protocol requests as identified by the requirement sending the HELD protocol requests as identified by the requirement
in the L7 LCP problem statement and requirements [11]. The discovery in the L7 LCP problem statement and requirements [11]. The discovery
methods are specified in [15]. methods are specified in [15].
Where a Device requires LI directly, it can request that the LCS Where a Device requires LI directly, it can request that the LCS
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. With this approach, the LCS needs to uniquely PIDF-LO document. With this approach, the LCS needs to uniquely
identify the Device within the access network. The source address of identify the Device within the access network. The source IP address
the request message is sufficient in most cases. Once the Device is of the request message is sufficient in most cases. Once the Device
identified, the LCS uses network domain-specific information to is identified, the LCS uses network domain-specific information to
determine the location of the Device. determine the location of the Device.
The details on the information that may be included in the PIDF-LO The details on the information that may be included in the PIDF-LO
MUST follow the subset of those rules relating to the construction of MUST follow the subset of those rules relating to the construction of
the "location-info" element in [10]. The PIDF-LO generated by the the "location-info" element in [10]. The PIDF-LO generated by the
LCS in this case MUST follow the rules in [10]. In addition, the LCS in this case MUST follow the rules in [10]. In addition, the
default values for <retransmission allowed> and <retention expires> default values for <retransmission-allowed> and <retention-expiry> as
as specified in [8] MUST be applied. A default value of "no" SHALL specified in [8] MUST be applied. A default value of "no" SHALL be
be used for the <retransmission-allowed> element. A default value of used for the <retransmission-allowed> element. A default value of 24
24 hours SHALL be used for <retention-expires> value of any generated hours SHALL be used for <retention-expiry> value of any generated
PDIF-LO documents. PIDF-LO documents. An LCS MAY provide a shorter value for
<retention-expiry> but MUST NOT provide a value longer than 24 hours.
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 [23] of any scheme, which literal location. A Location URI is a URI [23] of any scheme, which
a Location Recipient (LR) can use to retrieve LI. A location URI a Location Recipient (LR) can use to retrieve LI. A location URI
provided by an LCS can be assumed to be globally-addressable; that provided by an LCS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LCS. This does is, anyone in possession of the URI can access the LCS. This does
not in any way suggest that the LCS is bound to reveal the location not in any way suggest that the LCS is bound to reveal the location
associated with the location URI. This issue is deemed out of scope associated with the location URI. This issue is deemed out of scope
for this document. The merits and drawbacks of using a Location URI for this document. The merits and drawbacks of using a Location URI
approach are discussed in [16]. approach are discussed in [16].
6. Protocol Description 6. Protocol Description
As discussed in Section 5, this protocol provides for the retrieval As discussed in Section 5, this protocol provides for the retrieval
of a Location or a Location URI from an LCS. Three messages are of a Location or a Location URI from an LCS. Three messages are
defined to support the location retrieval: locationRequest, defined to support the location retrieval: locationRequest,
heldResponse and error. Messages are defined as XML documents. locationResponse and error. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 6.2. A Location Request from a Device indicates whether a Section 6.2. A Location Request from a Device indicates whether a
Location (and the specific type of location) and/or a Location URI Location (and the specific type of location) and/or a Location URI
should be returned. The LCS replies with a response (heldResponse), should be returned. The LCS replies with a response
including a PIDF-LO document and/or one or more Location URIs in case (locationResponse), including a PIDF-LO document and/or one or more
of success, or an error message in case of an error. Location URIs in case of success, or an error message in case of an
error.
A MIME type "application/held+xml" is registered in Section 12.6 to A MIME type "application/held+xml" is registered in Section 12.4 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 [20], including the naming convention of the type ('+xml' suffix) in [20], including the naming convention of the type ('+xml' suffix)
and the usage of the 'charset' parameter. and the usage of the 'charset' parameter.
Section 7 contains a more thorough description of the protocol Section 7 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 8 parameters, valid values, and how each should be handled. Section 8
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 [12]. messages in the form of an XML Schema [12].
skipping to change at page 10, line 6 skipping to change at page 10, line 14
6.2. Location Request 6.2. Location Request
A location request is sent from the Device to the LCS when it A location request is sent from the Device to the LCS when it
requires LI. This request MUST include the type of location being requires LI. This request MUST include the type of location being
requested such as civic location, location URI, etc. The type of LI requested such as civic location, location URI, etc. The type of LI
that a Device requests is determined by the type of LI that is that a Device requests is determined by the type of LI that is
included in the "locationType" element. included in the "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 successful response to a location "locationRequest" element. The LCS uses the source IP address of the
request is a document formed of a "heldResponse" element, unless the location request message as the primary source of identity for the
request fails, in which case the LCS SHOULD provide an error requesting device or target. It is anticipated that other Device
indication document. identities MAY be provided through schema extensions. The successful
response to a location request is a document formed of a
"locationResponse" element, unless the request fails, in which case
the LCS SHOULD provide an error indication document.
6.3. Held Response 6.3. Location Response
The response to a Location request MUST contain either a PIDF-LO The response to a Location request MUST contain either a PIDF-LO
and/or Location URI(s), depending upon the requested "locationType". and/or Location URI(s), depending upon the requested "locationType".
The "heldResponse" element MUST include a "code" attribute with a The "locationResponse" element MUST include a "code" attribute with a
value of 200. A set of predefined error codes are included in value of "success". A set of predefined error codes are included in
Section 7.4. The response is in error if there is a value other than Section 7.3. The response is in error if there is a value other than
200, since those MUST be sent using the error message Section 6.4. "success", since those MUST be sent using the error message
Section 6.4.
A Location URI MUST NOT contain any information that could be used to A Location URI MUST NOT contain any information that could be used to
identify the Device or Target. It is RECOMMENDED that a Location URI identify the Device or Target. It is RECOMMENDED that a Location URI
contain a public address for the LCS and a random sequence of contain a public address for the LCS and an anonymous identifier,
characters that the LCS can use to identify a particular context. such as a local identifer or unlinked pseudonym.
6.4. Indicating Errors 6.4. Indicating Errors
In the event of an error, the LCS SHOULD respond to the Device with In the event of an error, the LCS SHOULD respond to the Device with
an error document. The error response applies to all request types an error document. The error response applies to all request types
and SHOULD also be sent in response to any unrecognized request. and SHOULD also be sent in response to any unrecognized request.
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 7.4. Section 7.3. A code of "success" MUST NOT be used in an "error"
element.
Error responses MAY also include a "message" attribute that can Error responses MAY also include a "message" attribute that can
include additional information. This information SHOULD be for include additional information. This information SHOULD be for
diagnostic purposes only, and MAY be in any language. The language diagnostic purposes only, and MAY be in any language. The language
of the message SHOULD be indicated with an "xml:lang" attribute. of the message SHOULD be indicated with an "xml:lang" attribute.
7. Protocol Parameters 7. Protocol Parameters
This section describes, in detail the parameters that are used for This section describes, in detail the parameters that are used for
this protocol. Table 1 lists the top-level components used within this protocol. Table 1 lists the top-level components used within
the protocol and where they are mandatory or optional for each of the the protocol and where they are mandatory or optional for each of the
messages. messages.
+-------------------------+-----------------+---------------+-------+ +------------------------+----------------+-----------------+-------+
| Parameter | Location | HELD Response | Error | | Parameter | Location | Location | Error |
| | Request | | | | | Request | Response | |
+-------------------------+-----------------+---------------+-------+ +------------------------+----------------+-----------------+-------+
| responseTime | o | | | | responseTime | o | | |
| (Section 7.1) | | | | | (Section 7.1) | | | |
| locationType | m | | | | locationType | m | | |
| (Section 7.2) | | | | | (Section 7.2) | | | |
| exact (Section 7.2.1) | o | | | | exact (Section 7.2.1) | o | | |
| options (Section 7.3) | o | | | | code (Section 7.3) | | m | m |
| code (Section 7.4) | | m | m | | message (Section 7.4) | | o | o |
| message (Section 7.5) | | o | o |
| locationURI | | o | | | locationURI | | o | |
| (Section 7.6) | | | | | (Section 7.5) | | | |
| expires (Section 7.6.1) | | m | | | expires | | m | |
+-------------------------+-----------------+---------------+-------+ | (Section 7.5.1) | | | |
+------------------------+----------------+-----------------+-------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
7.1. "responseTime" Parameter 7.1. "responseTime" Parameter
The "responseTime" attribute indicates to the LCS how long the Device The "responseTime" attribute indicates to the LCS how long the Device
is prepared to wait for a response. This attribute MAY be added to a is prepared to wait for a response. This attribute MAY be added to a
Location request message. The value of this attribute is indicative Location request message. The value of this attribute is indicative
only, the LCS is under no obligation to strictly adhere to the time only, the LCS is under no obligation to strictly adhere to the time
limit implied; any enforcement of the time limit is left to the limit implied; any enforcement of the time limit is left to the
skipping to change at page 11, line 52 skipping to change at page 12, line 14
7.2. "locationType" Parameter 7.2. "locationType" Parameter
The "locationType" element is included in a location request. It The "locationType" element is included in a location request. It
contains a list of LI types that are requested by the Device. The contains a list of LI types that are requested by the Device. The
following list describes the possible values: following list describes the possible values:
any: The LCS SHOULD attempt to provide LI in all forms available to any: The LCS SHOULD attempt to provide LI in all forms available to
it. This value MUST be assumed as the default if no it. This value MUST be assumed as the default if no
"locationType" is specified. The LCS SHOULD return location "locationType" is specified. The LCS SHOULD return location
information in a form that is suited for routing and responding to information in a form that is suited for routing and responding to
an emergency call in its jurisdiction. an emergency call in its jurisdiction. The LCS MAY alternatively
or additionally return a location URI.
geodetic: The LCS SHOULD return a geodetic location for the Target. geodetic: The LCS SHOULD return a geodetic location for the Target.
civic: The LCS SHOULD return a civic address for the Target. Any civic: The LCS SHOULD return a civic address for the Target. Any
type of civic address may be returned. The LCS SHOULD ignore this type of civic address may be returned. The LCS SHOULD ignore this
value if a request for jurisdictional or postal civic address has value if a request for jurisdictional or postal civic address has
been made and can be satisfied. been made and can be satisfied.
jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic
address for the Target. address for the Target.
postalCivic: The LCS SHOULD return a postal civic address for the postalCivic: The LCS SHOULD return a postal civic address for the
Target. Target.
locationURI: The LCS SHOULD return a location URI for the Target. locationURI: The LCS SHOULD return a location URI for the Target.
skipping to change at page 12, line 37 skipping to change at page 12, line 48
that prefers a specific location type without causing location that prefers a specific location type without causing location
requests to fail when that location type is unavailable. Unless the requests to fail when that location type is unavailable. Unless the
"exact" attribute is set, the LCS MUST provide LI in any available "exact" attribute is set, the LCS MUST provide LI in any available
form if it is unable to comply with the request. form if it is unable to comply with the request.
For example, a notebook computer could be configured to retrieve For example, a notebook computer could be configured to retrieve
civic addresses, which is usually available from typical home or work civic addresses, which is usually available from typical home or work
situations. However, when using a wireless modem, the LCS might be situations. However, when using a wireless modem, the LCS might be
unable to provide a civic address. unable to provide a civic address.
7.2.1. "exact" Parameter 7.2.1. "exact" Attribute
When the "exact" attribute is set to "true", it indicates to the LCS When the "exact" attribute is set to "true", it indicates to the LCS
that the contents of the "locationType" parameter MUST be strictly that the contents of the "locationType" parameter MUST be strictly
followed. The default value of "false" allows the LCS the option of followed. The default value of "false" allows the LCS the option of
returning something beyond what is specified, such as a location URI returning something beyond what is specified, such as a location URI
when only a civic location was requested. when only a civic location was requested.
A value of "true" indicates that the LCS MUST provide a location of A value of "true" indicates that the LCS MUST provide a location of
the requested type or types or MUST provide an error. The LCS MUST the requested type or types or MUST provide an error. The LCS MUST
provide the requested types only and these types SHOULD be specified provide the requested types only and these types SHOULD be specified
in the same order as they were requested. The LCS SHOULD handle an in the same order as they were requested. The LCS SHOULD handle an
exact request that includes a "locationType" element set to "any" as exact request that includes a "locationType" element set to "any" as
if the "exact" attribute were set to "false". if the "exact" attribute were set to "false".
7.3. "options" Parameter 7.3. "code" Parameter
The "options" attribute provides for extensibility, allowing for the
definition of future optional extensions to the location request
message without the need to create a new namespace. If multiple
options are used, they MUST be separated by a semicolon (;), such as
"optionOne=1;optionTwo=2; Option3=3". Options MUST be registered
with IANA per Section 12.2.
7.4. "code" Parameter
All responses MUST contain a response code. The "code" attribute All responses MUST contain a response code. The "code" attribute
applies to the "error" and "heldResponse" messages. applies to the "error" and "locationResponse" messages. All errors
are application-level errors, and MUST only be provided in
successfully processed transport-level responses. For example where
HTTP is used as the transport, HELD error messages MUST be
accompanied by a 200 OK HTTP response.
The following response codes follow a three decimal form similar to HELD error responses may be one of the following tokens:
that in HTTP [3] and SIP [22]: success: This code indicates that the request was successful. This
200 (Success): This code indicates that the request was successful. code MUST not be used for an error response.
This code MUST not be used for an error response. requestError: This code indicates that the request was badly formed
400 (Request Error): This code indicates that the request was badly in some fashion.
formed in some fashion. xmlError: This code indicates that the XML content of the request
401 (XML Error): This code indicates that the XML content of the was either badly formed or invalid.
request was either badly formed or invalid. generalLcsError: This code indicates that an unspecified error
402 (Authentication Error): This code indicates that the request occurred at the LCS.
either did not contain authentication information, or the locationUnknown: This code indicates that the LCS could not
authentication provided was not accepted.
500 (General LCS Error): This code indicates that an unspecified
error occurred at the LCS.
501 (Location Unknown): This code indicates that the LCS could not
determine the location of the Device. determine the location of the Device.
502 (Unsupported Message): This code indicates that the request was unsupportedMessage: This code indicates that the request was not
not supported or understood by the LCS. supported or understood by the LCS.
503 (Timeout): This code indicates that the LCS could not satisfy timeout: This code indicates that the LCS could not satisfy the
the request within the time specified in the "responseTime" request within the time specified in the "responseTime" parameter.
parameter. cannotProvideLiType: This code indicates that the LCS was unable to
504 (Cannot Provide LI Type): This code indicates that the LCS was provide LI of the type or types requested. This code is used when
unable to provide LI of the type or types requested. This code is the "exact" attribute on the "locationType" parameter is set to
used when the "exact" attribute on the "locationType" parameter is "true".
set to "true".
Additional response codes within the x00 to x79 range MUST be
specified in published RFCs; the range from x80 to x99 is reserved
for private usage.
7.5. "message" Parameter 7.4. "message" Parameter
The "heldResponse" and "error" messages MAY include a "message" The "locationResponse" and "error" messages MAY include a "message"
attribute to convey some additional, human-readable information about attribute to convey some additional, human-readable information about
the result of the request. This message MAY be included in any the result of the request. This message MAY be included in any
language, which SHOULD be indicated by the "xml:lang", attribute. language, which SHOULD be indicated by the "xml:lang", attribute.
The default language is assumed to be English. The default language is assumed to be English.
7.6. "locationURI" Parameter 7.5. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each The "locationURI" element includes a single Location URI. Each
Location URI that is allocated by the LCS is unique to the device Location URI that is allocated by the LCS is unique to the device
that is requesting it. that is requesting it.
A "heldResponse" message MAY contain any number of "locationURI" A "locationResponse" message MAY contain any number of "locationURI"
elements. It is RECOMMENDED that the LCS allocate a Location URI for elements. It is RECOMMENDED that the LCS allocate a Location URI for
each scheme that it supports and that each scheme is present only each scheme that it supports and that each scheme is present only
once. URI schemes and their secure variants such as http and https once. URI schemes and their secure variants such as http and https
should be regarded as two separate schemes. should be regarded as two separate schemes.
7.6.1. "expires" Parameter 7.5.1. "expires" Parameter
The "expires" attribute indicates the time at which the Location URI The "expires" attribute indicates the time at which the Location URI
provided by the LCS will expire. This attribute is included in the provided by the LCS will expire. This attribute is included in the
"heldResponse" message only. "locationResponse" message only.
Responses to Locations requests for Location URIs MUST include the Responses to Locations requests for Location URIs MUST include the
expiry time of the Location URI. expiry time of the Location URI.
8. XML Schema 8. XML Schema
This section gives the XML Schema Definition [12] of the This section gives the XML Schema Definition [12] of the
"application/held+xml" format. This is presented as a formal "application/held+xml" format. This is presented as a formal
definition of the "application/held+xml" format. Note that the XML definition of the "application/held+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly Schema definition is not intended to be used with on-the-fly
skipping to change at page 15, line 21 skipping to change at page 15, line 20
<xs:import namespace="urn:ietf:params:xml:ns:pidf:geopriv10" <xs:import namespace="urn:ietf:params:xml:ns:pidf:geopriv10"
schemaLocation="geopriv10.xsd"/> schemaLocation="geopriv10.xsd"/>
<xs:import <xs:import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
schemaLocation="civicAddress.xsd"/> schemaLocation="civicAddress.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:common-policy" <xs:import namespace="urn:ietf:params:xml:ns:common-policy"
schemaLocation="common-policy.xsd"/> schemaLocation="common-policy.xsd"/>
<xs:import namespace="http://www.opengis.net/gml" <xs:import namespace="http://www.opengis.net/gml"
schemaLocation="GML-3.1.1/base/geometryBasic2d.xsd"/> schemaLocation="GML-3.1.1/base/geometryBasic2d.xsd"/>
<!-- Context Information --> <!-- Return Location -->
<xs:complexType name="returnContextType"> <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"
use="required"/> use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
skipping to change at page 16, line 31 skipping to change at page 16, line 29
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="held:locationTypeBase"> <xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean" <xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/> use="optional" default="false"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<!-- Response code --> <!-- Response code -->
<xs:simpleType name="codeType"> <xs:simpleType name="codeType">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:token">
<xs:pattern value="[0-5][0-9][0-9]"/> <xs:enumeration value="success"/>
<xs:enumeration value="requestError"/>
<xs:enumeration value="xmlError"/>
<xs:enumeration value="generalLcsError"/>
<xs:enumeration value="locationUnknown"/>
<xs:enumeration value="unsupportedMessage"/>
<xs:enumeration value="timeout"/>
<xs:enumeration value="cannotProvideLiType"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- Message Definitions --> <!-- Message Definitions -->
<xs:complexType name="baseRequestType"> <xs:complexType name="baseRequestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="responseTime" type="held:durationType" <xs:attribute name="responseTime" type="held:durationType"
use="optional"/> use="optional"/>
skipping to change at page 17, line 14 skipping to change at page 17, line 19
use="required"/> use="required"/>
<xs:attribute name="message" type="xs:token" <xs:attribute name="message" type="xs:token"
use="optional"/> use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="error" type="held:baseResponseType"/> <xs:element name="error" type="held:baseResponseType"/>
<!-- Context Response --> <!-- Location Response -->
<xs:complexType name="contextResponseType"> <xs:complexType name="locationResponseType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="held:baseResponseType"> <xs:extension base="held:baseResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="locationUriSet" <xs:element name="locationUriSet"
type="held:returnContextType" 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:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="heldResponse" <xs:element name="locationResponse"
type="held:contextResponseType"/> type="held:locationResponseType"/>
<!-- Location Request --> <!-- Location Request -->
<xs:annotation>
<xs:documentation>
locationRequest message requests a location
and/or a location URI. locationType being requested
is specified as an element. A locationURI is explicitly
requested by setting the locationURI attribute to true.
</xs:documentation>
</xs:annotation>
<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"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="options" type="xs:token"
use="optional"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
9. HTTP Binding 9. HTTP Binding
skipping to change at page 18, line 23 skipping to change at page 18, line 35
Description Language (WSDL) document in Section 9.1. Description Language (WSDL) document in Section 9.1.
The request is carried in this binding as the body of an HTTP POST The request is carried in this binding as the body of an HTTP POST
request. The MIME type of both request and response bodies should be request. The MIME type of both request and response bodies should be
"application/held+xml". "application/held+xml".
The LCS populates the HTTP headers so that they are consistent with The LCS populates the HTTP headers so that they are consistent with
the contents of the message. In particular, the "expires" and cache the contents of the message. In particular, the "expires" and cache
control headers are used to control the caching of any PIDF-LO control headers are used to control the caching of any PIDF-LO
document or Location URIs. The HTTP status code SHOULD have the same document or Location URIs. The HTTP status code SHOULD have the same
first digit as any "heldResponse" or "error" body included, and it first digit as any "locationResponse" or "error" body included, and
SHOULD indicate a 2xx series response when a PIDF-LO document or it SHOULD indicate a 2xx series response when a PIDF-LO document or
Location URI is included. Location URI is included.
This binding also includes a default behaviour, which is triggered by This binding also includes a default behaviour, which is triggered by
a GET request, or a POST with no request body. If either of these a GET request, or a POST with no request body. If either of these
queries are received, the LCS MUST attempt to provide either a queries are received, the LCS MUST attempt to provide either a
PIDF-LO document or a Location URI, as if the request was a location PIDF-LO document or a Location URI, as if the request was a location
request. request.
This binding MUST use TLS as described in [4]. TLS provides message This binding MUST use TLS as described in [4]. TLS provides message
integrity and privacy between Device and LCS. The LCS MUST use the integrity and privacy between Device and LCS. The LCS MUST use the
skipping to change at page 19, line 29 skipping to change at page 19, line 42
<xsd:import namespace="urn:ietf:params:xml:ns:geopriv:held" <xsd:import namespace="urn:ietf:params:xml:ns:geopriv:held"
schemaLocation="held.xsd"/> schemaLocation="held.xsd"/>
<xsd:import namespace="urn:ietf:params:xml:ns:pidf"/> <xsd:import namespace="urn:ietf:params:xml:ns:pidf"/>
</xsd:schema> </xsd:schema>
</wsdl:types> </wsdl:types>
<wsdl:interface name="held"> <wsdl:interface name="held">
<wsdl:operation name="locationRequest" method="POST"> <wsdl:operation name="locationRequest" method="POST">
<wsdl:input message="held:locationRequest"/> <wsdl:input message="held:locationRequest"/>
<wsdl:output message="held:heldResponse"/> <wsdl:output message="held:locationResponse"/>
<wsdl:fault message="held:error"/> <wsdl:fault message="held:error"/>
</wsdl:operation> </wsdl:operation>
<wsdl:operation <wsdl:operation
name="getLocation" method="GET" name="getLocation" method="GET"
pattern="http://www.w3.org/2004/08/wsdl/out-only"> pattern="http://www.w3.org/2004/08/wsdl/out-only">
<wsdl:output message="held:heldResponse"/> <wsdl:output message="held:locationResponse"/>
<wsdl:fault message="held:error"/> <wsdl:fault message="held:error"/>
</wsdl:operation> </wsdl:operation>
</wsdl:interface> </wsdl:interface>
<!-- Note that the by default the HTTP binding uses: <!-- Note that the by default the HTTP binding uses:
whttp:inputSerialization="application/xml" whttp:inputSerialization="application/xml"
whttp:outputSerializatiom="application/xml" whttp:outputSerializatiom="application/xml"
whttp:faultSerialization="application/xml" whttp:faultSerialization="application/xml"
whttp:location="" whttp:location=""
--> -->
<wsdl:binding name="heldHTTP" whttp:defaultMethod="POST"> <wsdl:binding name="heldHTTP" whttp:defaultMethod="POST">
skipping to change at page 20, line 44 skipping to change at page 21, line 10
Addressing information used in a request to the LCS is used to Addressing information used in a request to the LCS is used to
determine the identity of the Device, and to address a response. determine the identity of the Device, and to address a response.
This ensures that a Device can only request its own LI. This ensures that a Device can only request its own LI.
A temporary spoofing of IP address could mean that a device could A temporary spoofing of IP address could mean that a device could
request a Location URI that would result in another Device's request a Location URI that would result in another Device's
location. One or more of the follow approaches are RECOMMENDED to location. One or more of the follow approaches are RECOMMENDED to
limit this exposure: limit this exposure:
o Location URIs SHOULD have a limited lifetime, as reflected by the o Location URIs SHOULD have a limited lifetime, as reflected by the
value for the expires element (Section 7.6.1). value for the expires element (Section 7.5.1).
o The network SHOULD have mechanisms that protect against IP address o The network SHOULD have mechanisms that protect against IP address
spoofing. spoofing.
o The LCS SHOULD ensure that requests can only originate from within o The LCS SHOULD ensure that requests can only originate from within
its administrative domain. its administrative domain.
o The LCS and network SHOULD be configured so that the LCS is made o The LCS and network SHOULD be configured so that the LCS is made
aware of Device movement within the network and addressing aware of Device movement within the network and addressing
changes. If the LCS detects a change in the network, then all changes. If the LCS detects a change in the network, then all
location URIs MUST be invalidated. location URIs MUST be invalidated.
The above measures are dependent on network configuration and SHOULD The above measures are dependent on network configuration and SHOULD
be considered with circumstances in mind. For instance, in a fixed be considered with circumstances in mind. For instance, in a fixed
internet access, providers may be able to restrict the allocation of internet access, providers may be able to restrict the allocation of
IP addresses to a single physical line, ensuring that spoofing is not IP addresses to a single physical line, ensuring that spoofing is not
possible; in such an environment, other measures may not be possible; in such an environment, other measures may not be
skipping to change at page 21, line 42 skipping to change at page 22, line 11
The examples in this section show a complete HTTP message that The examples in this section show a complete HTTP message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that GET feature described by the HTTP binding. This example assumes that
the LCS service exists at the URL "https://lcs.example.com/location". the LCS service exists at the URL "https://lcs.example.com/location".
GET /location HTTP/1.1 GET /location HTTP/1.1
Host: lcs.example.com Host: lcs.example.com
Accept: application/pidf+xml,application/held+xml, Accept:application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
The GET request is exactly identical to a minimal POST request that The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST /location HTTP/1.1 POST /location HTTP/1.1
Host: lcs.example.com Host: lcs.example.com
Accept: application/pidf+xml,application/held+xml, Accept: application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The successful response to either of these requests is a PIDF-LO The successful response to either of these requests is a PIDF-LO
document. The following response shows a minimal PIDF-LO response. document. The following response shows a minimal PIDF-LO response.
HTTP/1.x 200 OK HTTP/1.x 200 OK
Server: Example LCS Server: Example LCS
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/pidf+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 594
<?xml version="1.0"?> <?xml version="1.0"?>
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" code="success"
message="OK"> message="OK">
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com"> entity="pres:3650n87934c@ls.example.com">
<tuple id="3b650sf789nd"> <tuple id="3b650sf789nd">
<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-expires> <retention-expiry>
2006-01-11T03:42:28+00:00</retention-expires> 2006-01-11T03:42:28+00:00</retention-expiry>
</usage-rules> </usage-rules>
</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>
</heldResponse> </locationResponse>
The error response to either of these requests is an error document. The error response to either of these requests is an error document.
The following response shows an example error response. The following response shows an example error response.
HTTP/1.x 500 Server Error HTTP/1.x 200 OK
Server: Example LCS Server: Example LCS
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" code="501" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"
message="Unable to determine location"/> message="Unable to determine location"/>
Note: To focus on important portions of messages, all examples Note: To focus on important portions of messages, all examples
following this note do not show HTTP headers or the XML prologue. following this note do not show HTTP headers or the XML prologue.
In addition, sections of XML not relevant to the example are In addition, sections of XML not relevant to the example are
replaced with comments. replaced with comments.
11.2. Simple Location Request Example 11.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 response to this location request is a list of Location URIs. The response to this location request is a list of Location URIs.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK"> code="success" message="OK">
<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>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</heldResponse> </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" code="450" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"
message="Location not available"/> message="Location not available"/>
11.3. Location Request Example with options 11.3. Location Request Example for Multiple Location Types
The location request shown below specifies a response time and an
option, but doesn't specify any location type.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="2"
options="optionOne=1;"/>
The corresponding HELD response shown below includes a PIDF-LO.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv>
<location-info>
<gs:Circle
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules>
<retransmission-allowed>false</retransmission-allowed>
<retention-expires>2007-05-25T12:35:02+10:00
</retention-expires>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</heldResponse>
A corresponding HELD response with Location URIs.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
</heldResponse>
11.4. 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, jurisdictional civic and any Location URIs. geodetic, jurisdictional 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
jurisdictionalCivic jurisdictionalCivic
locationURI locationURI
</locationType> </locationType>
</locationRequest> </locationRequest>
The corresponding HELD 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.
<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="200" message="OK"> code="success" message="OK">
<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>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>sips: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:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv> <geopriv>
<location-info> <location-info>
<gs:Circle <gs:Circle
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" 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 28, line 29 skipping to change at page 26, line 16
<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> <retransmission-allowed>false</retransmission-allowed>
<retention-expires>2007-05-25T12:35:02+10:00 <retention-expiry>2007-05-25T12:35:02+10:00
</retention-expires> </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>
</heldResponse> </locationResponse>
11.5. Sample LCS WSDL Document 11.4. Sample LCS WSDL Document
The following WSDL document demonstrates how a WSDL document can be The following WSDL document demonstrates how a WSDL document can be
created for a specific service, in this case, a service at the URI created for a specific service, in this case, a service at the URI
"https://lcs.example.com/location". "https://lcs.example.com/location".
<?xml version="1.0"?> <?xml version="1.0"?>
<wsdl:definitions <wsdl:definitions
xmlns:wsdl="http://www.w3.org/2005/05/wsdl" xmlns:wsdl="http://www.w3.org/2005/05/wsdl"
xmlns:heldhttp="urn:ietf:params:xml:ns:geopriv:held:http" xmlns:heldhttp="urn:ietf:params:xml:ns:geopriv:held:http"
targetNamespace="http://lcs.example.com/ws/held"> targetNamespace="http://lcs.example.com/ws/held">
skipping to change at page 29, line 30 skipping to change at page 27, line 7
<wsdl:service name="sample-held-svc" interface="heldhttp:held"> <wsdl:service name="sample-held-svc" interface="heldhttp:held">
<wsdl:endpoint name="sample-held-ep" <wsdl:endpoint name="sample-held-ep"
binding="heldhttp:heldHTTP" binding="heldhttp:heldHTTP"
address="https://lcs.example.com/location"/> address="https://lcs.example.com/location"/>
</wsdl:service> </wsdl:service>
</wsdl:definitions> </wsdl:definitions>
12. IANA Considerations 12. IANA Considerations
According to the guidelines in [6], this document calls for an IANA This document registers an XML namespace and schema and the
registry for result codes and a registry for options in the "application/held+xml" MIME type.
locationRequest. This document also registers an XML namespace and
schema and the "application/held+xml" MIME type.
12.1. IANA Registry for HELD Result Codes
IANA will establish and maintain a registry of HELD result codes.
Additional values are registered based on the "specification
required" option in [6].
Specifications MUST specify the following information when
registering new values in this registry:
Code Value: A three-digit value from 000 to 679. The last 20 codes
in each block of 100 (from x80 to x99) are reserved for private or
experimental use and cannot be registered.
Short Message: A brief message that describes the general reason for
the code.
Publication: A reference to any relevant publication or
specification.
Description and Usage: A longer description of the code and the
circumstances where it applies. This description does not need to
be exhaustive.
The values in Section 7.4 are pre-registered in this registry.
12.2. IANA Registry for HELD Location Request Options
IANA will establish and maintain a registry of HELD Location Request
options to allow for extensibility of the request. Values are
registered based on the "specification required" option in [6].
Specifications MUST specify the following information when
registering new values in this registry:
Option: Name of the option.
Short Message: A brief message that describes the general reason for
the option and valid values and ranges.
Publication: A reference to any relevant publication or
specification.
Description and Usage: A longer description of the option and the
circumstances where it applies. This description does not need to
be exhaustive.
12.3. URN Sub-Namespace Registration for 12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6].
URI: urn:ietf:params:xml:ns:geopriv:held URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
skipping to change at page 31, line 23 skipping to change at page 27, line 38
<body> <body>
<h1>Namespace for HELD Messages</h1> <h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2> <h2>urn:ietf:params:xml:ns:geopriv:held</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
12.4. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in [6]. This section registers an XML schema as per the guidelines in [6].
URI: urn:ietf:params:xml:schema:geopriv:held URI: urn:ietf:params:xml:schema:geopriv:held
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).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 8 of this document. Section 8 of this document.
12.5. URN Sub-Namespace Registration for 12.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:http urn:ietf:params:xml:ns:geopriv:held:http
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in
[6]. [6].
URI: urn:ietf:params:xml:ns:geopriv:held:http URI: urn:ietf:params:xml:ns:geopriv:held:http
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
skipping to change at page 32, line 23 skipping to change at page 28, line 28
<body> <body>
<h1>Namespace for HELD HTTP Binding WS</h1> <h1>Namespace for HELD HTTP Binding WS</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:http</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:http</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
12.6. MIME Media Type Registration for 'application/held+xml' 12.4. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
UTF-8. UTF-8.
skipping to change at page 33, line 17 skipping to change at page 29, line 24
Author/Change controller: This specification is TBD Author/Change controller: This specification is TBD
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [20], and many of the considerations described application/xml [20], and many of the considerations described
there also apply to application/held+xml. there also apply to application/held+xml.
13. Contributors 13. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors James Winterbottom, Martin Thomson and Barbara Stark are the authors
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. section. James Winterbottom also contributed to the WG document.
14. Acknowledgements 14. Acknowledgements
The author/contributors would like to thank the following people for The author/contributors would like to thank the following people for
their constructive input to this document (in alphabetical order): their constructive input to this document (in alphabetical order):
Nadine Abbott, Guy Caron, Martin Dawson, Jerome Grenier, Neil Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome
Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, John Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk,
Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Tschofenig. John Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes
Tschofenig.
15. References 15. Changes since last Version
15.1. Normative References NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC.
Changes from WG 00 to 01:
1) heldResponse renamed to locationResponse.
2) Changed namespace references for the PIDF-LO geoShape in the
schema to match the agreed GML PIDF-LO Geometry Shape Application
Schema.
3) Removed "options" element - leaving optionality/extensibility to
XML mechanisms.
4) Changed error codes to be enumerations and not redefinitions of
HTTP response codes.
5) Updated schema/examples for the above and removed some remnants of
the context element.
6) Clarified the definition of "Location Information (LI)" to include
a reference to the location (to match the XML schema and provide
consistency of usage throughout the document). Added an additional
statement in section 7.2 (locationType) to clarify that LCS MAY also
return a Location URI.
7) Modifed the definition of "Location Configuration Server (LCS)" to
be consistent with the current definiton in the requirements
document.
8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in
this document.
10) Miscellaneous editorial clarifications.
16. References
16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 34, line 17 skipping to change at page 31, line 20
[8] Peterson, J., "A Presence-based GEOPRIV Location Object [8] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), February 2007. progress), February 2007.
[10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, [10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations", Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-07 (work in progress), draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
April 2007. July 2007.
[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements", Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007.
[12] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML [12] Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML
Schema Part 1: Structures Second Edition", World Wide Web Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028, 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>.
[13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second [13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
Edition", World Wide Web Consortium Recommendation REC- Edition", World Wide Web Consortium Recommendation REC-
xmlschema-2-20041028, October 2004, 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 35, line 5 skipping to change at page 32, line 5
[15] Thomson, M. and J. Winterbottom, "Discovering the Local [15] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-00 (work in progress), draft-thomson-geopriv-lis-discovery-00 (work in progress),
February 2007. February 2007.
[16] Marshall, R., "Requirements for a Location-by-Reference [16] Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance", Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in progress), draft-marshall-geopriv-lbyr-requirements-01 (work in progress),
March 2007. March 2007.
15.2. Informative References 16.2. Informative References
[17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[18] Myers, J., "Simple Authentication and Security Layer (SASL)", [18] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
[19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000. and Instant Messaging", RFC 2778, February 2000.
skipping to change at page 35, line 34 skipping to change at page 32, line 34
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[24] Polk, J. and B. Rosen, "Session Initiation Protocol Location [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-07 (work in Conveyance", draft-ietf-sip-location-conveyance-07 (work in
progress), February 2007. progress), February 2007.
[25] Mendelsohn, N., Gudgin, M., Nielsen, H., Moreau, J., and M. [25] Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and M.
Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World
Wide Web Consortium FirstEdition REC-soap12-part1-20030624, Wide Web Consortium FirstEdition REC-soap12-part1-20030624,
June 2003, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[26] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. [26] Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and J.
Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
Consortium FirstEdition REC-soap12-part2-20030624, June 2003, Consortium FirstEdition REC-soap12-part2-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
[27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web [27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web
Services Description Language (WSDL) Version 2.0 Part 1: Core Services Description Language (WSDL) Version 2.0 Part 1: Core
Language", W3C CR CR-wsdl20-20060106, January 2006. Language", W3C CR CR-wsdl20-20060106, January 2006.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
skipping to change at page 36, line 14 skipping to change at page 33, line 14
specified in the [11]. specified in the [11].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The LIS MUST be presented with a unique identifier of its own "The LIS MUST be presented with a unique identifier of its own
addressing realm associated in some way with the physical location of addressing realm associated in some way with the physical location of
the end host." the end host."
COMPLY COMPLY
The identifier used may be the source address of the request packet HELD uses the IP address of the location request message as the
and/or additional client identifier values relevant to the scope of primary source of identity for the requesting device or target. This
the access network provided within the request. Mapping an IP identity can be used with other contextual network information to
address into lower-level attachment data is access network dependent provide a physical location for the Target for many network
and is the responsibility the LIS. deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the
scope of this document.
A.2. L7-2: Mobility Support A.2. L7-2: Mobility Support
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from devices that can only move between broad range of mobility from devices that can only move between
reboots, to devices that can change attachment points with the impact reboots, to devices that can change attachment points with the impact
that their IP address is changed, to devices that do not change their that their IP address is changed, to devices that do not change their
IP address while roaming, to devices that continuously move by being IP address while roaming, to devices that continuously move by being
attached to the same network attachment point." attached to the same network attachment point."
 End of changes. 90 change blocks. 
318 lines changed or deleted 263 lines changed or added

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