draft-ietf-geopriv-http-location-delivery-01.txt   draft-ietf-geopriv-http-location-delivery-02.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: January 10, 2008 Expires: March 30, 2008
July 9, 2007 September 27, 2007
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-01.txt draft-ietf-geopriv-http-location-delivery-02.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 January 10, 2008. This Internet-Draft will expire on March 30, 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
location information either by-value or by-reference. The protocol location information either by-value or by-reference. The protocol
supports mobile and nomadic devices through Location URIs. The is an application-layer protocol that is independent of session-
protocol is an application-layer protocol that is independent of layer; an HTTP, web services binding is specified.
session-layer; an HTTP, web services binding is specified.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 7
6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 8
6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 8
6.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 8
6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8
7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 9
7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 10
7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 10
7.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 11
7.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 11
7.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 6.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 11
7.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14 6.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 12
7.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 16
9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.1. Return Routability . . . . . . . . . . . . . . . . . . . . 18
10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 9.2. Transaction Layer Security . . . . . . . . . . . . . . . . 19
10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 19
11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21 10.2. Simple Location Request Example . . . . . . . . . . . . . 22
11.2. Simple Location Request Example . . . . . . . . . . . . . 24 10.3. Location Request Example for Multiple Location Types . . . 23
11.3. Location Request Example for Multiple Location Types . . . 25 10.4. Sample LIS WSDL Document . . . . . . . . . . . . . . . . 24
11.4. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11.1. URN Sub-Namespace Registration for
12.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 25
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 25
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27 11.3. URN Sub-Namespace Registration for
12.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 25
urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 27 11.4. MIME Media Type Registration for 'application/held+xml' . 26
12.4. MIME Media Type Registration for 'application/held+xml' . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 14. Changes since last Version . . . . . . . . . . . . . . . . . . 27
15. Changes since last Version . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 31
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 32 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 31
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 33 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 31
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 33 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 32
A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 33 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 32
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 34 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 32
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 34 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 33
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 35 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 33
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 35 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 33
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 35 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 34
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 35 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 36
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 Location Configuration Protocol (LCP)
document [11] provides some scenarios in which a Device might rely on problem statement and requirements document [11] provides some
its access network to provide the location information, such as such scenarios in which a Device might rely on its access network to
as fixed environments (e.g., DSL/Cable), mobile networks and wireless provide the location information, such as fixed environments (e.g.,
access networks. This document describes a protocol that can be used DSL/Cable), mobile networks and wireless access networks. This
to acquire Location Information (LI) from a service within an access document describes a protocol that can be used to acquire Location
network. The service within an access network is assumed to be Information (LI) from a Location Information Server (LIS) within an
provided by a Location Configuration Server (LCS), as introduced in access network.
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 LIS by-value, that is, the Device may acquire
that is, the Device may acquire a literal location object describing a literal location object describing the location of the Device.
the location of the Device. Alternatively, the Device may request Alternatively, the Device may request that the LIS provide a location
that the LCS provide a location reference in the form of a location reference in the form of a location URI or set of location URIs,
URI or set of location URIs, allowing the Device to distribute its LI allowing the Device to distribute its LI by-reference. Both of these
by-reference. Both of these methods are compatible, and both can be methods are compatible, and both can be provided concurrently from
provided concurrently from the same LCS so that application needs can the same LIS so that application needs can be addressed individually.
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 LIS 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 & Terminology
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
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
3. Terminology
This document uses the terms (and their acronym forms) Access This document uses the terms (and their acronym forms) Access
Provider (AP), Location Information (LI), Location Object (LO), Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Server (LS), Location Generator (LG), Device, Target, Location Generator (LG), Location Recipient (LR),
Location Recipient (LR), Rule Maker (RM) and Rule Holder (RH) as Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
defined in [7]. This document also includes definitions for the Requirements [7] . The terms Location Information Server (LIS),
terms, Civic Location/Address, Geodetic Location, and Location Access Network, Access Provider (AP) and Access Network Provider are
Configuration Server, used within this document. These definitions used in the same context as defined in the L7 LCP Problem statement
may differ slightly from those used in other GEOPRIV documents, but and Requirements document [11]. The usage of the terms, Civic
the concepts are the same. Location/Address and Geodetic Location follows the usage in many of
the referenced documents.
For convenience, abbreviated versions of RFC 3693 [7] definitions are
included. Notes are included following some of the definitions to
clarify the context in which these terms are used in this document:
Access Network Provider: See Access Provider (AP).
Access Provider (AP): An organization that provides physical network
connectivity to its customers or users, e.g., through digital
subscriber lines, cable TV plants, Ethernet, leased lines or radio
frequencies. Examples of such organizations include
telecommunication carriers, municipal utilities, larger
enterprises with their own network infrastructure, and government
organizations such as the military.
Note: this definition differs from that in [7] by the use of the
more generic 'organization' rather than 'domain' - the general
concept is the same. This term is used interchangeably with
Access Network Provider in this document.
Civic Location/Address: A location expressed in a form that is
defined by civic demarcations. Civic addresses can be specialized
for jurisdictional (general use) or postal (message delivery)
purposes, or they can apply to either.
Device: The technical device whereby the location is tracked as a
proxy for the location of a Target.
Geodetic Location: A location expressed in coordinate form.
Location Configuration Server (LCS): The entity within the Access
Provider's network that provides location information to clients.
This term is introduced in [11] and refers to an entity capable of
determining the location of an end point and providing that
location information via the Location Configuration Protocol (LCP)
to the requesting party. The requesting party is the end point
itself or an authorized entity that acts on its behalf.
Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location Objects
describing that location.
Location Information (LI): The data that describes the location of a
Device, either by-value or by-reference. The term LI does not
include the representation of this data.
Note: this terms is not officially defined in [7], but rather is
assumed from the general usage throughout that document and within
the GEOPRIV WG.
Location Object (LO): An object conveying Location Information (and
possibly privacy rules) to which Geopriv security mechanisms and
privacy rules are to be applied.
Note: this is a specific by-value representation of Location
Information (LI). In this document, LO refers to PIDF-LO [8].
Location Server (LS): The LS is an element that receives
publications of Location Objects from Location Generators and may
receive subscriptions from Location Recipients. The LS applies
the rules (which it learns from the Rule Holder) to LOs it
receives from LGs, and then notifies LRs of resulting LOs as
necessary.
Note: This definition varies from that defined in [7] by defining
the roles of the functional elements more explicitly. In some
specifications the Location Server is referred to as a Location
Information Server or LIS. In this context, the Location Server
is distinct from what is alternatively referred to as a Registrar
in other contexts.
Location Recipient (LR): The entity that receives Location
Information (LI).
Rule Holder (RH): The entity that provides the rules associated with
a particular target for the distribution of Location Information
(LI).
Rule Maker (RM): The authority that creates rules governing access
to location information for a target (typically, this it the
Target themselves).
Target: A person or other entity whose location is communicated by a
GEOPRIV Location Object (LO).
4. Overview and Scope 3. Overview and Scope
This document describes an interface between a Device and a Location This document describes an interface between a Device and a Location
Configuration Server (LCS). The LCS is a service present within the Information Server (LIS). The LIS is present within the same
same administrative domain as the Device (the access network). An administrative domain as the Device (the access network). An Access
Access Provider (AP) operates the LCS service so that Devices (and Provider (AP) operates the LIS so that Devices (and Targets) can
Targets) can retrieve LI. The LCS exists because not all Devices are retrieve LI. The LIS exists because not all Devices are capable of
capable of determining LI, and because, even if a device is able to determining LI, and because, even if a device is able to determine
determine its own LI, it may be more efficient with assistance. This its own LI, it may be more efficient with assistance. This document
document does not specify how LI is derived. 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
be retrieved from a Location Configuration Server (LCS) by-value,
that is, the Device may acquire a literal location in ther form of a
PIDF-LO. Alternatively, the Device may request that the LCS provide
a location reference in the form of a location URI or set of location
URIs, allowing the Device to distribute its LI by-reference.
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 LIS 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 |
| | | |
| +--------------------------------------+ | | +--------------------------------------+ |
| | Location Configuration Server | | | | Location Information Server | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +------|---------------------'---------+ | | +------|---------------------'---------+ |
+----------|---------------------'------------+ +----------|---------------------'------------+
| ' | '
| ' | '
HELD APP HELD APP
| ' | '
Rule Maker - _ +-----------+ +-----------+ Rule Maker - _ +-----------+ +-----------+
o - - | Device | | Location | o - - | Device | | Location |
<U\ | | - - - - | Recipient | <U\ | | - - - - | Recipient |
/ \ _ - - | | APP | | / \ _ - - | | APP | |
Target - - +-----------+ +-----------+ Target - - +-----------+ +-----------+
Figure 1: Significant Roles Figure 1: Significant Roles
The interface between the Location Recipient (LR) and the Device The interface between the Location Recipient (LR) and the Device
and/or LCS is application specific, as indicated by the APP and/or LIS is application specific, as indicated by the APP
annotation in the diagram and it is outside the scope of the annotation in the diagram and it is outside the scope of the
document. An example of an APP interface between a device and LR can document. An example of an APP interface between a device and LR can
be found in the SIP Location Conveyance document [24]. be found in the SIP Location Conveyance document [22].
5. Protocol Overview 4. 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 MAY be specified in separate specifications as of this document and may be specified in separate specifications as
required. The Device must first discover the URI for the LCS for required. The Device must first discover the URI for the LIS 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 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. With this approach, the LCS needs to uniquely PIDF-LO document. With this approach, the LIS needs to uniquely
identify the Device within the access network. The source IP address identify the Device within the access network. The source IP address
of the request message is sufficient in most cases. Once the Device of the request message is sufficient in most cases. Once the Device
is identified, the LCS uses network domain-specific information to is identified, the LIS 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 the PIDF-LO Usage Clarification,
LCS in this case MUST follow the rules in [10]. In addition, the Considerations and Recommendations document [10]. The LIS MUST
default values for <retransmission-allowed> and <retention-expiry> as follow those rules in generating the PIDF-LO in this case. Per the
specified in [8] MUST be applied. A default value of "no" SHALL be GEOPRIV Location Object format specified in [8], the "entity" element
used for the <retransmission-allowed> element. A default value of 24 MUST reflect the Target of the Location Information. In addition,
hours SHALL be used for <retention-expiry> value of any generated the default values for <retransmission-allowed> and <retention-
PIDF-LO documents. An LCS MAY provide a shorter value for expiry> as specified in [8] MUST be applied. A default value of "no"
SHALL be used for the <retransmission-allowed> element. A default
value of 24 hours SHALL be used for <retention-expiry> value of any
generated PIDF-LO documents. A LIS MAY provide a shorter value for
<retention-expiry> but MUST NOT provide a value longer than 24 hours. <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 [21] 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 a LIS can be assumed to be globally-addressable; that is,
is, anyone in possession of the URI can access the LCS. This does anyone in possession of the URI can access the LIS. This does not in
not in any way suggest that the LCS is bound to reveal the location any way suggest that the LIS 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 5. Protocol Description
As discussed in Section 5, this protocol provides for the retrieval As discussed in Section 4, 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 a LIS. Three messages are
defined to support the location retrieval: locationRequest, defined to support the location retrieval: locationRequest,
locationResponse 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 5.2. A Location Request message from a Device indicates
Location (and the specific type of location) and/or a Location URI whether a Location (and the specific type of location) and/or a
should be returned. The LCS replies with a response Location URI should be returned. The LIS replies with a response
(locationResponse), including a PIDF-LO document and/or one or more (locationResponse), including a PIDF-LO document and/or one or more
Location URIs in case of success, or an error message in case of an Location URIs in case of success, or an error message in case of an
error. error.
A MIME type "application/held+xml" is registered in Section 12.4 to A MIME type "application/held+xml" is registered in Section 11.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 [19], 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 6 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 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 [12]. messages in the form of an XML Schema [12].
6.1. Protocol Binding 5.1. Protocol Binding
The HELD protocol is an application-layer protocol that is defined The HELD protocol is an application-layer protocol that is defined
independently of any lower layers. This means that any protocol can independently of any lower layers. This means that any protocol can
be used to transport this protocol providing that it can provide a be used to transport this protocol providing that it can provide a
few basic features: few basic features:
o The protocol must have acknowledged delivery. o The protocol must have acknowledged delivery.
o The protocol must be able to correlate a response with a request. o The protocol must be able to correlate a response with a request.
o The protocol must provide authentication, privacy and protection o The protocol must provide authentication, privacy and protection
against modification. against modification.
Candidate protocols that could be used to address these purposes This document includes a binding that uses a combination of HTTP [3],
include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21] TLS [2] and TCP [17] in Section 8.
and SOAP [25] [26]. This document includes a binding that uses a
combination of HTTP, TLS and TCP in Section 9.
6.2. Location Request 5.2. Location Request
A location request is sent from the Device to the LCS when it A location request message is sent from the Device to the LIS when it
requires LI. This request MUST include the type of location being requires LI. The type of LI that a Device requests is determined by
requested such as civic location, location URI, etc. The type of LI the type of LI that is included in the "locationType" element.
that a Device requests is determined by the type of LI that is
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 LCS 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. The successful identities MAY be provided through schema extensions. The successful
response to a location request is a document formed of a response to a location request message is a document formed of a
"locationResponse" element, unless the request fails, in which case "locationResponse" element, unless the request fails, in which case
the LCS SHOULD provide an error indication document. the LIS MUST provide an error indication document.
6.3. Location Response The LIS MUST ignore any part of a location request message that it
does not understand.
5.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 "locationResponse" element MUST include a "code" attribute with a
value of "success". A set of predefined error codes are included in
Section 7.3. The response is in error if there is a value other than
"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 an anonymous identifier, contain a public address for the LIS and an anonymous identifier,
such as a local identifer or unlinked pseudonym. such as a local identifer or unlinked pseudonym.
6.4. Indicating Errors 5.4. Indicating Errors
In the event of an error, the LCS SHOULD respond to the Device with In the event of an error, the LIS MUST respond to the Device with an
an error document. The error response applies to all request types error document. The error response applies to all request types and
and SHOULD also be sent in response to any unrecognized request. MUST 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.3. A code of "success" MUST NOT be used in an "error" Section 6.3.
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 6. 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 | Location | Error | | Parameter | Location | Location | Error |
| | Request | Response | | | | Request | Response | |
+------------------------+----------------+-----------------+-------+ +------------------------+----------------+-----------------+-------+
| responseTime | o | | | | responseTime | o | | |
| (Section 7.1) | | | | | (Section 6.1) | | | |
| locationType | m | | | | locationType | o | | |
| (Section 7.2) | | | | | (Section 6.2) | | | |
| exact (Section 7.2.1) | o | | | | exact (Section 6.2.1) | o | | |
| code (Section 7.3) | | m | m | | code (Section 6.3) | | m | m |
| message (Section 7.4) | | o | o | | message (Section 6.4) | | | o |
| locationURI | | o | | | locationURI | | o | |
| (Section 7.5) | | | | | (Section 6.5) | | | |
| expires | | m | | | expires | | m | |
| (Section 7.5.1) | | | | | (Section 6.5.1) | | | |
+------------------------+----------------+-----------------+-------+ +------------------------+----------------+-----------------+-------+
Table 1: Message Parameter Usage Table 1: Message Parameter Usage
7.1. "responseTime" Parameter 6.1. "responseTime" Parameter
The "responseTime" attribute indicates to the LCS how long the Device The "responseTime" attribute is optional and indicates to the LIS how
is prepared to wait for a response. This attribute MAY be added to a long the Device is prepared to wait for a response and/or the purpose
Location request message. The value of this attribute is indicative for which the Device needs the location. In the case of emergency
only, the LCS is under no obligation to strictly adhere to the time services, the purpose of obtaining the LI could be either for routing
limit implied; any enforcement of the time limit is left to the a call to the appropriate PSAP or indicating the location to which
requesting Device. responders should be dispatched. The time values defined for those
purposes, emergencyRouting and emergencyDispatch, will likely be
governed by jurisdictional policies, and SHOULD be configurable on
the LIS.
This attribute is expressed with a decimal seconds value, which may The value of the time attribute is 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 requesting Device. The
time attribute is expressed with a decimal seconds value, which may
include a decimal point. It is RECOMMENDED that systems support include a decimal point. It is RECOMMENDED that systems support
millisecond precision for this parameter. millisecond precision for this parameter. The LIS SHOULD provide the
most accurate LI that can be determined within the specified interval
for the specific service.
The LCS MUST provide the most accurate LI that can be determined The LIS MAY use the value of the "responseTime" attribute as input
within the specified interval. This parameter could be used as input
when selecting the method of location determination, where multiple when selecting the method of location determination, where multiple
such methods exist. If this parameter is absent, then the LCS MUST such methods exist. If this parameter is absent, then the LIS MUST
return the most precise LI it is capable of determining. return the most precise LI it is capable of determining.
7.2. "locationType" Parameter 6.2. "locationType" Parameter
The "locationType" element is included in a location request. It The "locationType" element MAY be included in a location request
contains a list of LI types that are requested by the Device. The message. It contains a list of LI types that are requested by the
following list describes the possible values: Device. The following list describes the possible values:
any: The LCS SHOULD attempt to provide LI in all forms available to any: The LIS 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 LIS 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. The LCS MAY alternatively an emergency call in its jurisdiction. The LIS MAY alternatively
or additionally return a location URI. or additionally return a location URI.
geodetic: The LCS SHOULD return a geodetic location for the Target. geodetic: The LIS SHOULD return a geodetic location for the Target.
civic: The LCS SHOULD return a civic address for the Target. Any civic: The LIS 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.
value if a request for jurisdictional or postal civic address has locationURI: The LIS SHOULD return a location URI for the Target.
been made and can be satisfied.
jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic
address for the Target.
postalCivic: The LCS SHOULD return a postal civic address for the
Target.
locationURI: The LCS SHOULD return a location URI for the Target.
The LCS SHOULD return the requested location type or types. The LCS The LIS SHOULD return the requested location type or types. The LIS
MAY provide additional location types, or it MAY provide alternative MAY provide additional location types, or it MAY provide alternative
types if the request cannot be satisfied for a requested location types if the request cannot be satisfied for a requested location
type. If the "exact" attribute is present and set to "true" in a type. If the "exact" attribute is present and set to "true" in a
location request, then a successful LCS response MUST provide the location request, then a successful LIS response MUST provide the
requested location type only, with no additional location requested location type only, with no additional location
information. The "exact" attribute has no effect when this element information. The "exact" attribute has no effect when this element
is set to "any". is set to "any".
The "SHOULD"-strength requirement on this parameter is included to The "SHOULD"-strength requirement on this parameter is included to
allow for soft-failover. This enables a fixed client configuration allow for soft-failover. This enables a fixed client configuration
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 LIS 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 LIS might be
unable to provide a civic address. unable to provide a civic address and thus provides a geodetic
address.
7.2.1. "exact" Attribute 6.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 LIS
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 LIS 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 LIS 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 LIS MUST
provide the requested types only and these types SHOULD be specified provide the requested types only. The LIS MUST handle an exact
in the same order as they were requested. The LCS SHOULD handle an request that includes a "locationType" element set to "any" as if the
exact request that includes a "locationType" element set to "any" as "exact" attribute were set to "false".
if the "exact" attribute were set to "false".
7.3. "code" Parameter 6.3. "code" Parameter
All responses MUST contain a response code. The "code" attribute All "error" responses MUST contain a response code. All errors are
applies to the "error" and "locationResponse" messages. All errors application-level errors, and MUST only be provided in successfully
are application-level errors, and MUST only be provided in processed transport-level responses. For example where HTTP is used
successfully processed transport-level responses. For example where as the transport, HELD error messages MUST be accompanied by a 200 OK
HTTP is used as the transport, HELD error messages MUST be HTTP response.
accompanied by a 200 OK HTTP response.
HELD error responses may be one of the following tokens: HELD error responses may be one of the following tokens:
success: This code indicates that the request was successful. This
code MUST not be used for an error response.
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
was either badly formed or invalid. was either badly formed or invalid.
generalLcsError: This code indicates that an unspecified error generalLisError: This code indicates that an unspecified error
occurred at the LCS. occurred at the LIS.
locationUnknown: This code indicates that the LCS could not locationUnknown: This code indicates that the LIS could not
determine the location of the Device. determine the location of the Device.
unsupportedMessage: This code indicates that the request was not unsupportedMessage: This code indicates that the request was not
supported or understood by the LCS. supported or understood by the LIS.
timeout: This code indicates that the LCS 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 LCS 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".
7.4. "message" Parameter 6.4. "message" Parameter
The "locationResponse" and "error" messages MAY include a "message" The "error" message MAY include a "message" attribute to convey some
attribute to convey some additional, human-readable information about additional, human-readable information about the result of the
the result of the request. This message MAY be included in any request. This message MAY be included in any language, which SHOULD
language, which SHOULD be indicated by the "xml:lang", attribute. be indicated by the "xml:lang", attribute. The default language is
The default language is assumed to be English. assumed to be English.
7.5. "locationURI" Parameter 6.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 LIS is unique to the device
that is requesting it. that is requesting it.
A "locationResponse" 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 LIS 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. MUST be regarded as two separate schemes.
7.5.1. "expires" Parameter 6.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 LIS will expire. This attribute is included in the
"locationResponse" 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 7. 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
validation of the presence XML document. validation of the presence XML document.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held" targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
skipping to change at page 14, line 48 skipping to change at page 12, line 37
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation source="https://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] --> published RFC and remove this note.]] -->
This document defines HELD messages. This document defines HELD messages.
</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="xml.xsd"/> schemaLocation="xml.xsd"/>
<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"/>
skipping to change at page 15, line 15 skipping to change at page 13, line 4
</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="xml.xsd"/> schemaLocation="xml.xsd"/>
<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"
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"/>
<!-- 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"
use="required"/> use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- Duration Type --> <!-- responseTime Type -->
<xs:simpleType name="durationType"> <xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:decimal"> <xs:restriction base="xs:decimal">
<xs:minInclusive value="0.0"/> <xs:minInclusive value="0.0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- 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:list> <xs:list>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="civic"/> <xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/> <xs:enumeration value="geodetic"/>
<xs:enumeration value="postalCivic"/>
<xs:enumeration value="jurisdictionalCivic"/>
<xs:enumeration value="locationURI"/> <xs:enumeration value="locationURI"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
</xs:union> </xs:union>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="locationTypeType"> <xs:complexType name="locationTypeType">
<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:token"> <xs:restriction base="xs:token">
<xs:enumeration value="success"/>
<xs:enumeration value="requestError"/> <xs:enumeration value="requestError"/>
<xs:enumeration value="xmlError"/> <xs:enumeration value="xmlError"/>
<xs:enumeration value="generalLcsError"/> <xs:enumeration value="generalLisError"/>
<xs:enumeration value="locationUnknown"/> <xs:enumeration value="locationUnknown"/>
<xs:enumeration value="unsupportedMessage"/> <xs:enumeration value="unsupportedMessage"/>
<xs:enumeration value="timeout"/> <xs:enumeration value="timeout"/>
<xs:enumeration value="cannotProvideLiType"/> <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:responseTimeType"
use="optional"/> use="optional"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="baseResponseType">
<xs:complexType name="errorType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence/> <xs:sequence/>
<xs:attribute name="code" type="held:codeType" <xs:attribute name="code" type="held:codeType"
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:errorType"/>
<!-- Location Response --> <!-- Location Response -->
<xs:complexType name="locationResponseType"> <xs:complexType name="locationResponseType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="held:baseResponseType"> <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:extension> </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 -->
<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: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 8. HTTP Binding
This section defines an HTTP [3] binding for this protocol, which all This section defines an HTTP [3] binding for this protocol, which all
conforming implementations MUST support. This binding takes the form conforming implementations MUST support. This binding takes the form
of a Web Service (WS) that can be described by the Web Services of a Web Service (WS) that can be described by the Web Services
Description Language (WSDL) document in Section 9.1. Description Language (WSDL) document in Section 8.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 LIS 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 indicate a
first digit as any "locationResponse" or "error" body included, and 2xx series response when a PIDF-LO document or Location URI is
it SHOULD indicate a 2xx series response when a PIDF-LO document or 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 LIS 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 LIS. The LIS MUST use the
server authentication method described in [4]; the Device MUST fail a server authentication method described in [4]; the Device MUST fail a
request if server authentication fails, except in the event of an request if server authentication fails, except in the event of an
emergency. emergency.
9.1. HTTP Binding WSDL 8.1. HTTP Binding WSDL
The following WSDL 2.0 [27] document describes the HTTP binding for The following WSDL 2.0 [23] document describes the HTTP binding for
this protocol. Actual service instances MUST provide a "service" this protocol. Actual service instances MUST provide a "service"
with at least one "endpoint" that implements the "heldHTTP" binding. with at least one "endpoint" that implements the "heldHTTP" binding.
A service description document MAY include this schema directly or by A service description document MAY include this schema directly or by
using the "import" or "include" directives. using the "import" or "include" directives.
<?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:whttp="http://www.w3.org/2005/05/wsdl/http" xmlns:whttp="http://www.w3.org/2005/05/wsdl/http"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
skipping to change at page 20, line 4 skipping to change at page 17, line 33
<wsdl:output message="held:locationResponse"/> <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:locationResponse"/> <wsdl:output message="held:locationResponse"/>
<wsdl:fault message="held:error"/> <wsdl:fault message="held:error"/>
</wsdl:operation> </wsdl:operation>
</wsdl:interface>
<!-- Note that the by default the HTTP binding uses: </wsdl:interface>
whttp:inputSerialization="application/xml"
whttp:outputSerializatiom="application/xml"
whttp:faultSerialization="application/xml"
whttp:location=""
-->
<wsdl:binding name="heldHTTP" whttp:defaultMethod="POST"> <wsdl:binding name="heldHTTP" whttp:defaultMethod="POST">
<wsdl:operation ref="heldhttp:locationRequest"/> <wsdl:operation
<wsdl:operation ref="heldhttp:getLocation" whttp:method="GET"/> whttp:inputSerialization="application/held+xml"
whttp:outputSerializatiom="application/held+xml"
whttp:faultSerialization="application/held+xml"
ref="heldhttp:locationRequest"/>
<wsdl:operation
whttp:inputSerialization="application/held+xml"
whttp:outputSerializatiom="application/held+xml"
whttp:faultSerialization="application/held+xml"
ref="heldhttp:getLocation" whttp:method="GET"/>
</wsdl:binding> </wsdl:binding>
</wsdl:definitions> </wsdl:definitions>
10. Security Considerations 9. Security Considerations
The threat model for this protocol assumes that the LCS exists within The threat model for this protocol assumes that the LIS exists within
the same administrative domain as the Device. The LCS requires the same administrative domain as the Device. The LIS requires
access to network information so that it can determine Location. access to network information so that it can determine Location.
Therefore, the LCS can use network information to protect against a Therefore, the LIS can use network information to protect against a
number of the possible attacks. number of the possible attacks.
Specific requirements and security considerations for location Specific requirements and security considerations for location
acquisition protocols are provided in [11] including that the LCP acquisition protocols are provided in [11] including that the LCP
MUST NOT assume prior network access authentication, which is MUST NOT assume prior network access authentication, which is
addressed in Section 10.2 addressed in Section 9.2
An in-depth discussion of the security considerations applicable to An in-depth discussion of the security considerations applicable to
the use of Location URIs and by-reference provision of LI is included the use of Location URIs and by-reference provision of LI is included
in [16]. in [16].
10.1. Return Routability 9.1. Return Routability
It is RECOMMENDED that Location Configuration Servers use return It is RECOMMENDED that Location Information Servers use return
routability rather than requiring Device authentication. Device routability rather than requiring Device authentication. Device
authentication SHOULD NOT be required due to the administrative authentication SHOULD NOT be required due to the administrative
challenge of issuing and managing of client credentials, particularly challenge of issuing and managing of client credentials, particularly
when networks allow visiting users to attach devices. However, the when networks allow visiting users to attach devices. However, the
LCS MAY require any form of authentication as long as these factors LIS MAY require any form of authentication as long as these factors
are considered. are considered.
Addressing information used in a request to the LCS is used to Addressing information used in a request to the LIS 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.5.1). value for the expires element (Section 6.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 LIS 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 LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing aware of Device movement within the network and addressing
changes. If the LCS detects a change in the network, then all changes. If the LIS 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
necessary. necessary.
10.2. Transaction Layer Security 9.2. Transaction Layer Security
All bindings for this protocol MUST ensure that messages are All bindings for this protocol MUST ensure that messages are
adequately protected against eavesdropping and modification. adequately protected against eavesdropping and modification.
Bindings MUST also provide a means of authenticating the LCS. Bindings MUST also provide a means of authenticating the LIS.
It is RECOMMENDED that all bindings also use TLS [2]. It is RECOMMENDED that all bindings also use TLS [2].
For the HTTP binding, TLS MUST be used. TLS provides protection For the HTTP binding, TLS MUST be used. TLS provides protection
against eavesdropping and modification. The server authentication against eavesdropping and modification. The server authentication
methods described in HTTP on TLS [4] MUST be used. methods described in HTTP on TLS [4] MUST be used.
11. Examples 10. Examples
11.1. Simple HTTP Binding Example Messages 10.1. Simple HTTP Binding Example Messages
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 LIS service exists at the URL "https://lis.example.com/location".
GET /location HTTP/1.1 GET /location HTTP/1.1
Host: lcs.example.com Host: lis.example.com
Accept: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: lis.example.com
Accept: 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 LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 594 Content-Length: 594
<?xml version="1.0"?> <?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
code="success"
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>
skipping to change at page 24, line 8 skipping to change at page 22, line 8
</geopriv> </geopriv>
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
The error response to either of these requests is an error document. The error response to 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 200 OK HTTP/1.x 200 OK
Server: Example LCS Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 135 Content-Length: 135
<?xml version="1.0"?> <?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Unable to determine location"/> message="Unable to determine location"/>
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 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 response to this location request is a list of Location URIs. The response to this location request is a list of Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
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>
</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"/>
11.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, jurisdictional 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
jurisdictionalCivic civic
locationURI locationURI
</locationType> </locationType>
</locationRequest> </locationRequest>
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">
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>
skipping to change at page 26, line 27 skipping to change at page 24, line 26
</retention-expiry> </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.4. Sample LCS WSDL Document 10.4. Sample LIS 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://lis.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://lis.example.com/ws/held">
<wsdl:import <wsdl:import
namespace="urn:ietf:params:xml:ns:geopriv:held:http"/> namespace="urn:ietf:params:xml:ns:geopriv:held:http"/>
<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://lis.example.com/location"/>
</wsdl:service> </wsdl:service>
</wsdl:definitions> </wsdl:definitions>
12. IANA Considerations 11. IANA Considerations
This document registers an XML namespace and schema and the This document registers an XML namespace and schema and the
"application/held+xml" MIME type. "application/held+xml" MIME type.
12.1. URN Sub-Namespace Registration for 11.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 27, line 38 skipping to change at page 25, 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.2. XML Schema Registration 11.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 7 of this document.
12.3. URN Sub-Namespace Registration for 11.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:
skipping to change at page 28, line 28 skipping to change at page 26, 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.4. MIME Media Type Registration for 'application/held+xml' 11.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.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [20], section 3.2. 3023 [19], section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could protocol data related to the location of an entity, which could
include information that is considered private. Appropriate include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this precautions should be taken to limit disclosure of this
information. information.
Interoperability considerations: This content type provides a basis Interoperability considerations: This content type provides a basis
for a protocol for a protocol
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]] replace XXXX with the RFC number for this specification.]]
Applications which use this media type: Location information Applications which use this media type: Location information
providers and consumers. providers and consumers.
Additional Information: Magic Number(s): (none) Additional Information: Magic Number(s): (none)
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
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 [19], and many of the considerations described
there also apply to application/held+xml. there also apply to application/held+xml.
13. Contributors 12. 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. James Winterbottom also contributed to the WG document. section. In addition, they also contributed to the WG document, in
particular the schema and WSDL.
14. Acknowledgements 13. 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, Eric Arolick, Guy Caron, Martin Dawson, Jerome Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome
Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk,
John Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Carl Reed, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Tschofenig. Shrum, and Hannes Tschofenig.
15. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 01 to 02:
1) Updated Terminology to be consistent with WG agreements and other
documents (e.g., LCS -> LIS and removed duplicate terms). In the
end, there are no new terms defined in this document.
2) Modified definition of responseTime to reflect WG consensus.
3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
just "civic").
4) Clarified text that locationType is optional. Fixed table 1 and
text in section 5.2 (locationRequest description). Text in section
6.2 (description of locationType element) already defined the default
to be "any".
5) Simplified error responses. Separated the definition of error
response type from the locationResponse type thus no need for
defining an error code of "success". This simplifies the schema and
processing.
6) Updated schema/examples for the above.
7) Updated Appendix A based on updates to requirements document,
specifically changes to A.1, A.3 and adding A.10.
8) Miscellaneous editorial clarifications.
Changes from WG 00 to 01: Changes from WG 00 to 01:
1) heldResponse renamed to locationResponse. 1) heldResponse renamed to locationResponse.
2) Changed namespace references for the PIDF-LO geoShape in the 2) Changed namespace references for the PIDF-LO geoShape in the
schema to match the agreed GML PIDF-LO Geometry Shape Application schema to match the agreed GML PIDF-LO Geometry Shape Application
Schema. Schema.
3) Removed "options" element - leaving optionality/extensibility to 3) Removed "options" element - leaving optionality/extensibility to
XML mechanisms. XML mechanisms.
skipping to change at page 30, line 32 skipping to change at page 29, line 13
8) Updated Location Response (section 6.3) to remove reference to 8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security. pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the 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 identifier for the target/device for the HELD protocol as defined in
this document. this document.
10) Miscellaneous editorial clarifications. 10) Miscellaneous editorial clarifications.
16. References 15. References
16.1. Normative References 15.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 31, line 25 skipping to change at page 30, line 7
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-08 (work in progress), draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
July 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-05 (work in progress),
September 2007.
[12] Thompson, H., Mendelsohn, N., Maloney, M., 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>.
[14] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, [14] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language (GML)", "Geographic information - Geography Markup Language (GML)",
OpenGIS 03-105r1, April 2004, OpenGIS 03-105r1, April 2004,
<http://portal.opengeospatial.org/files/?artifact_id=4700>. <http://portal.opengeospatial.org/files/?artifact_id=4700>.
[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-03 (work in progress),
February 2007. September 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", draft-ietf-geopriv-lbyr-requirements-00 (work in
draft-marshall-geopriv-lbyr-requirements-01 (work in progress), progress), September 2007.
March 2007.
16.2. Informative References 15.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] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
RFC 2222, October 1997.
[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.
[20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [19] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[21] Rose, M., "The Blocks Extensible Exchange Protocol Core", [20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
RFC 3080, March 2001.
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [21] 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 [22] Polk, J. and B. Rosen, "Location Conveyance for the Session
Conveyance", draft-ietf-sip-location-conveyance-07 (work in Initiation Protocol", draft-ietf-sip-location-conveyance-08
progress), February 2007. (work in progress), July 2007.
[25] Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and M.
Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World
Wide Web Consortium FirstEdition REC-soap12-part1-20030624,
June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[26] Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and J.
Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web
Consortium FirstEdition REC-soap12-part2-20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.
[27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web [23] 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
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
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 L7 LCP MUST be able to carry different identifiers or MUST
addressing realm associated in some way with the physical location of define an identifier that is mandatory to implement. Regarding the
the end host." latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service
maintains identifier to location mapping."
COMPLY COMPLY
HELD uses the IP address of the location request message as the HELD uses the IP address of the location request message as the
primary source of identity for the requesting device or target. This primary source of identity for the requesting device or target. This
identity can be used with other contextual network information to identity can be used with other contextual network information to
provide a physical location for the Target for many network provide a physical location for the Target for many network
deployments. There may be network deployments where an IP address deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However, alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the any necessary identity extensions for these networks is beyond the
skipping to change at page 33, line 47 skipping to change at page 32, line 13
provides specific support for mobile environments by providing an provides specific support for mobile environments by providing an
optional responseTime attribute in location request messages. optional responseTime attribute in location request messages.
Wireless networks often have several different mechanisms at their Wireless networks often have several different mechanisms at their
disposal for position determination (e.g. Assisted GPS versus disposal for position determination (e.g. Assisted GPS versus
location based on serving base station identity), each providing location based on serving base station identity), each providing
different degrees of accuracy and taking different amounts of time to different degrees of accuracy and taking different amounts of time to
yield a result. The responseTime parameter provides the LIS with a yield a result. The responseTime parameter provides the LIS with a
criterion which it can use to select a location determination criterion which it can use to select a location determination
technique. technique.
A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the L7 LCP MUST NOT assume a business or trust
MUST NOT assume a business or trust relationship between the provider relationship between the Application Service Provider (ASP) and the
of application layer (e.g., SIP, XMPP, H.323) provider and the access Access Network Provider. Requirements for resolving a reference to
network provider operating the LIS." location information are not discussed in this document."
COMPLY COMPLY
HELD describes a location acquisition protocol and has no HELD describes a location acquisition protocol and has no
dependencies on how location is used once it has been acquired. dependencies on the business or trust relationship between the ASP
Location acquisition using HELD is subject to the restrictions and the Access Network Provider. Location acquisition using HELD is
described in Section 10. subject to the restrictions described in Section 9.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes same host are different entities, they cooperate for the purposes
needed to determine end system locations." needed to determine end system locations."
COMPLY COMPLY
HELD was specifically designed with this model in mind and readily HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change allows itself to chaining requests between operators without a change
in protocol being required. HELD is a webservices protocol it can be in protocol being required. HELD is a webservices protocol it can be
bound to transports other than HTTP, such as BEEP. Using a transport bound to transports other than HTTP. Using o offers the option of
like BEEP for HELD offers the option of high request throughput over high request throughput over a dedicated connection between an L3
a dedicated connection between an L3 provider and an L2 provider provider and an L2 provider without incurring the serial restriction
without incurring the serial restriction imposed by HTTP. This is imposed by HTTP. This is less easy to do with protocols that do not
less easy to do with protocols that do not decouple themselves from decouple themselves from the transport.
the transport.
A.5. L7-5: Legacy Device Considerations A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be upgraded to support additional protocols, environment that cannot be upgraded to support additional protocols,
for example to pass additional information through DHCP." for example to pass additional information through DHCP."
COMPLY COMPLY
skipping to change at page 35, line 39 skipping to change at page 34, line 4
HELD strongly recommends the use of TLS with server-side certificates HELD strongly recommends the use of TLS with server-side certificates
for communication between the end-point and the LIS. There is no for communication between the end-point and the LIS. There is no
requirement for the end-point to authenticate with the LIS. requirement for the end-point to authenticate with the LIS.
A.8. L7-8: Network Topology Unawareness A.8. L7-8: Network Topology Unawareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their public topology. End systems are, however, able to determine their public
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
COMPLY COMPLY
HELD makes no assumption about the network topology. HELD doesn't HELD makes no assumption about the network topology. HELD doesn't
require that the device know its external IP address, except where require that the device know its external IP address, except where
that is required for discovery of the LCS. that is required for discovery of the LIS.
A.9. L7-9: Discovery Mechanism A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery "The L7 LCP MUST define a single mandatory to implement discovery
mechanism." mechanism."
COMPLY COMPLY
HELD uses the discovery mechanism in [15]. HELD uses the discovery mechanism in [15].
A.10. L7-10: PIDF-LO Creation
"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
(see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the
rules outlined in ". [10]
COMPLY
HELD protocol overview (Section 4 ) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [10].
Authors' Addresses Authors' Addresses
Mary Barnes (editor) Mary Barnes (editor)
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
 End of changes. 178 change blocks. 
474 lines changed or deleted 392 lines changed or added

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