GEOPRIV WG                                                M. Barnes, Ed.
Internet-Draft                                                    Nortel
Intended status: Standards Track
Expires: January 10, March 30, 2008

                                                            July 9,

                                                      September 27, 2007

                 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

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, March 30, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   A Layer 7 Location Configuration Protocol (L7 LCP) is described that
   is used for retrieving location information from a server within an
   access network.  The protocol includes options for retrieving
   location information either by-value or by-reference.  The protocol
   supports mobile and nomadic devices through Location URIs.  The
   protocol
   is an application-layer protocol that is independent of
   session-layer; session-
   layer; an HTTP, web services binding is specified.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3. & Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.
   3.  Overview and Scope . . . . . . . . . . . . . . . . . . . . . .  6
   5.  4
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  6
   5.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  7
     5.1.  Protocol Binding . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  7
     5.2.  Location Request . . . . . . . . . . . . . . . . . . . . . 10
     6.3.  8
     5.3.  Location Response  . . . . . . . . . . . . . . . . . . . . 10
     6.4.  8
     5.4.  Indicating Errors  . . . . . . . . . . . . . . . . . . . . 10
   7.  8
   6.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  8
     6.1.  "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
     7.2.  9
     6.2.  "locationType" Parameter . . . . . . . . . . . . . . . . . 12
       7.2.1. 10
       6.2.1.  "exact" Attribute  . . . . . . . . . . . . . . . . . . 12
     7.3. 10
     6.3.  "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
     7.4. 11
     6.4.  "message" Parameter  . . . . . . . . . . . . . . . . . . . 13
     7.5. 11
     6.5.  "locationURI" Parameter  . . . . . . . . . . . . . . . . . 14
       7.5.1. 11
       6.5.1.  "expires" Parameter  . . . . . . . . . . . . . . . . . 14
   8. 12
   7.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9. 12
   8.  HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1. 16
     8.1.  HTTP Binding WSDL  . . . . . . . . . . . . . . . . . . . . 19
   10. 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     10.1. 18
     9.1.  Return Routability . . . . . . . . . . . . . . . . . . . . 20
     10.2. 18
     9.2.  Transaction Layer Security . . . . . . . . . . . . . . . . 21
   11. 19
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. 19
     10.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21
     11.2. 19
     10.2. Simple Location Request Example  . . . . . . . . . . . . . 24
     11.3. 22
     10.3. Location Request Example for Multiple Location Types . . . 25
     11.4. 23
     10.4. Sample LCS LIS  WSDL Document  . . . . . . . . . . . . . . . . 26
   12. 24
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     12.1. 25
     11.1. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held  . . . . . . . . . . . 27
     12.2. 25
     11.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 27
     12.3. 25
     11.3. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 27
     12.4. 25
     11.4. MIME Media Type Registration for 'application/held+xml'  . 28
   13. 26
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
   14. 27
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   15. 27
   14. Changes since last Version . . . . . . . . . . . . . . . . . . 29
   16. 27
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     16.1. 29
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     16.2. 29
     15.2. Informative References . . . . . . . . . . . . . . . . . . 32 30
   Appendix A.  HELD Compliance to IETF LCP requirements  . . . . . . 32 31
     A.1.  L7-1: Identifier Choice  . . . . . . . . . . . . . . . . . 33 31
     A.2.  L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 33 31
     A.3.  L7-3: Layer 7 ASP and Layer 2/3 Access Network Provider Relationship . . . . 33 32
     A.4.  L7-4: Layer 2 and Layer 3 Provider Relationship  . . . . . 34 32
     A.5.  L7-5: Legacy Device Considerations . . . . . . . . . . . . 34 32
     A.6.  L7-6: VPN Awareness  . . . . . . . . . . . . . . . . . . . 35 33
     A.7.  L7-7: Network Access Authentication  . . . . . . . . . . . 35 33
     A.8.  L7-8: Network Topology Unawareness . . . . . . . . . . . . 35 33
     A.9.  L7-9: Discovery Mechanism  . . . . . . . . . . . . . . . . 35 34
     A.10. L7-10: PIDF-LO Creation  . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 37 36

1.  Introduction

   The location of a Device is information that is useful for a number
   of applications.  The L7 LCP Location Configuration Protocol (LCP)
   problem statement and requirements document [11] provides some
   scenarios in which a Device might rely on its access network to
   provide the location information, such as such
   as fixed environments (e.g.,
   DSL/Cable), mobile networks and wireless access networks.  This
   document describes a protocol that can be used to acquire Location
   Information (LI) from a service Location Information Server (LIS) within an
   access network.  The service within an access network is assumed to be
   provided by a Location Configuration Server (LCS), as introduced in
   the L7 LCP problem statement and requirements document.

   This specification identifies two methods for acquiring LI.  Location
   may be retrieved from a Location Configuration Server (LCS) LIS by-value, that is, the Device may acquire
   a literal location object describing the location of the Device.
   Alternatively, the Device may request that the LCS LIS 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.  Both of these
   methods are compatible, and both can be provided concurrently from
   the same LCS LIS so that application needs can be addressed individually.

   This specification defines an XML-based protocol that enables the
   retrieval of LI from a LCS LIS by a Device.  This protocol can be bound
   to any session-layer protocol, particularly those capable of MIME
   transport; an HTTP binding is included as a minimum requirement.

2.  Conventions & Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

3.  Terminology

   This document uses the terms (and their acronym forms) Access
   Provider (AP), Location Information (LI), Location Object (LO),
   Device, Target, Location Server (LS), Location Generator (LG), Location Recipient (LR),
   Rule Maker (RM) and Rule Holder (RH) as defined in [7].  This document also includes definitions for the
   terms, Civic Location/Address, Geodetic Location, and Location
   Configuration Server, used within this document.  These definitions
   may differ slightly from those used in other GEOPRIV documents, but
   the concepts are the same.

   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 3693, GEOPRIV
   Requirements [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, Information Server (LIS),
   Access Network, Access Provider (AP) and then notifies LRs of resulting LOs Access Network Provider are
   used in the same context as
      necessary.
      Note: This definition varies from that defined in [7] by defining the roles L7 LCP Problem statement
   and Requirements document [11].  The usage of the functional elements more explicitly.  In some
      specifications the Location Server is referred to as a terms, Civic
   Location/Address and Geodetic Location
      Information Server or LIS.  In this context, follows the Location Server
      is distinct from what is alternatively referred to as a Registrar usage 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 many 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. referenced documents.

3.  Overview and Scope

   This document describes an interface between a Device and a Location
   Configuration
   Information Server (LCS). (LIS).  The LCS LIS is a service present within the same
   administrative domain as the Device (the access network).  An Access
   Provider (AP) operates the LCS service LIS so that Devices (and Targets) can
   retrieve LI.  The LCS LIS exists because not all Devices are capable of
   determining LI, and because, even if a device is able to determine
   its own LI, it may be more efficient with assistance.  This document
   does not specify how LI is derived.

   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
   that location determination technologies are generally designed to
   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
   for the end user's LI.  Since revealing the location of the device
   almost invariably reveals some information about the location of the
   user of the device, the same level of privacy protection demanded by
   a user is required for the device.  This approach may require either
   some additional assurances about the link between device and target,
   or an acceptance of the limitation that unless the device requires
   active user authentication, there is no guarantee that any particular
   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
   functional elements identified in [7] and the LCS LIS defined in [11] and
   where this protocol applies, with the Rule Maker and Target
   represented by the role of the Device.

                     +---------------------------------------------+
                     | Access Network Provider                     |
                     |                                             |
                     |   +--------------------------------------+  |
                     |   | Location Configuration Information Server          |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   +------|---------------------'---------+  |
                     +----------|---------------------'------------+
                                |                     '
                                |                     '
                               HELD                  APP
                                |                     '
     Rule Maker   - _     +-----------+         +-----------+
           o          - - | Device    |         | Location  |
          <U\             |           | - - - - | Recipient |
          / \       _ - - |           |   APP   |           |
         Target - -       +-----------+         +-----------+
                        Figure 1: Significant Roles

   The interface between the Location Recipient (LR) and the Device
   and/or LCS LIS is application specific, as indicated by the APP
   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
   be found in the SIP Location Conveyance document [24].

5. [22].

4.  Protocol Overview

   The HELD protocol facilitates retrieval of LI either by-value, as a
   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
   of this document and MAY may be specified in separate specifications as
   required.  The Device must first discover the URI for the LCS LIS for
   sending the HELD protocol requests as identified by the requirement
   in the L7 LCP problem statement and requirements [11].  The discovery
   methods are specified in [15].

   Where a Device requires LI directly, it can request that the LCS LIS
   create a PIDF-LO document.  This approach fits well with a
   configuration whereby the device directly makes use of the provided
   PIDF-LO document.  With this approach, the LCS LIS needs to uniquely
   identify the Device within the access network.  The source IP address
   of the request message is sufficient in most cases.  Once the Device
   is identified, the LCS LIS uses network domain-specific information to
   determine the location of the Device.

   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
   the "location-info" element in the PIDF-LO Usage Clarification,
   Considerations and Recommendations document [10].  The PIDF-LO generated by LIS MUST
   follow those rules in generating the
   LCS PIDF-LO in this case MUST follow case.  Per the rules
   GEOPRIV Location Object format specified in [10]. [8], the "entity" element
   MUST reflect the Target of the Location Information.  In addition,
   the default values for <retransmission-allowed> and <retention-expiry> <retention-
   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.  An LCS  A LIS MAY provide a shorter value for
   <retention-expiry> but MUST NOT provide a value longer than 24 hours.

   Requesting location directly does not always address the requirements
   of an application.  A Device can request a location URI instead of
   literal location.  A Location URI is a URI [23] [21] of any scheme, which
   a Location Recipient (LR) can use to retrieve LI.  A location URI
   provided by an LCS a LIS can be assumed to be globally-addressable; that is,
   anyone in possession of the URI can access the LCS. LIS.  This does not in
   any way suggest that the LCS LIS is bound to reveal the location
   associated with the location URI.  This issue is deemed out of scope
   for this document.  The merits and drawbacks of using a Location URI
   approach are discussed in [16].

6.

5.  Protocol Description

   As discussed in Section 5, 4, this protocol provides for the retrieval
   of a Location or a Location URI from an LCS. a LIS.  Three messages are
   defined to support the location retrieval: locationRequest,
   locationResponse and error.  Messages are defined as XML documents.

   The Location Request (locationRequest) message is described in
   Section 6.2. 5.2.  A Location Request message from a Device indicates
   whether a Location (and the specific type of location) and/or a
   Location URI should be returned.  The LCS LIS replies with a response
   (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
   error.

   A MIME type "application/held+xml" is registered in Section 12.4 11.4 to
   distinguish HELD messages from other XML document bodies.  This
   specification follows the recommendations and conventions described
   in [20], [19], including the naming convention of the type ('+xml' suffix)
   and the usage of the 'charset' parameter.

   Section 7 6 contains a more thorough description of the protocol
   parameters, valid values, and how each should be handled.  Section 8 7
   contains a more specific definition of the structure of these
   messages in the form of an XML Schema [12].

6.1.

5.1.  Protocol Binding

   The HELD protocol is an application-layer protocol that is defined
   independently of any lower layers.  This means that any protocol can
   be used to transport this protocol providing that it can provide a
   few basic features:
   o  The protocol must have acknowledged delivery.
   o  The protocol must be able to correlate a response with a request.
   o  The protocol must provide authentication, privacy and protection
      against modification.
   Candidate protocols that could be used to address these purposes
   include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21]
   and SOAP [25] [26].
   This document includes a binding that uses a combination of HTTP, HTTP [3],
   TLS [2] and TCP [17] in Section 9.

6.2. 8.

5.2.  Location Request

   A location request message is sent from the Device to the LCS LIS when it
   requires LI.  This request MUST include the type of location being
   requested such as civic location, location URI, etc.  The type of LI that a Device requests is determined by
   the type of LI that is included in the "locationType" element.

   The location request is made by sending a document formed of a
   "locationRequest" element.  The LCS LIS uses the source IP address of the
   location request message as the primary source of identity for the
   requesting device or target.  It is anticipated that other Device
   identities MAY be provided through schema extensions.  The successful
   response to a location request message is a document formed of a
   "locationResponse" element, unless the request fails, in which case
   the LCS SHOULD LIS MUST provide an error indication document.

6.3.

   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
   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
   identify the Device or Target.  It is RECOMMENDED that a Location URI
   contain a public address for the LCS LIS and an anonymous identifier,
   such as a local identifer or unlinked pseudonym.

6.4.

5.4.  Indicating Errors

   In the event of an error, the LCS SHOULD LIS MUST respond to the Device with an
   error document.  The error response applies to all request types and SHOULD
   MUST also be sent in response to any unrecognized request.

   An error indication document consists of an "error" element.  The
   "error" element MUST include a "code" attribute that indicates the
   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"
   element. 6.3.

   Error responses MAY also include a "message" attribute that can
   include additional information.  This information SHOULD be for
   diagnostic purposes only, and MAY be in any language.  The language
   of the message SHOULD be indicated with an "xml:lang" attribute.

7.

6.  Protocol Parameters

   This section describes, in detail the parameters that are used for
   this protocol.  Table 1 lists the top-level components used within
   the protocol and where they are mandatory or optional for each of the
   messages.

   +------------------------+----------------+-----------------+-------+
   | Parameter              |    Location    |     Location    | Error |
   |                        |     Request    |     Response    |       |
   +------------------------+----------------+-----------------+-------+
   | responseTime           |        o       |                 |       |
   | (Section 7.1) 6.1)          |                |                 |       |
   | locationType           |        m        o       |                 |       |
   | (Section 7.2) 6.2)          |                |                 |       |
   | exact (Section 7.2.1) 6.2.1)  |        o       |                 |       |
   | code (Section 7.3) 6.3)     |                |        m        |   m   |
   | message (Section 7.4) 6.4)  |                |        o                 |   o   |
   | locationURI            |                |        o        |       |
   | (Section 7.5) 6.5)          |                |                 |       |
   | expires                |                |        m        |       |
   | (Section 7.5.1) 6.5.1)        |                |                 |       |
   +------------------------+----------------+-----------------+-------+

                     Table 1: Message Parameter Usage

7.1.

6.1.  "responseTime" Parameter

   The "responseTime" attribute is optional and indicates to the LCS LIS how
   long the Device is prepared to wait for a response.  This attribute MAY response and/or the purpose
   for which the Device needs the location.  In the case of emergency
   services, the purpose of obtaining the LI could be added to either for routing
   a
   Location request message. call to the appropriate PSAP or indicating the location to which
   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.

   The value of this the time attribute is indicative
   only, only and the LCS 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.

   This  The
   time attribute is expressed with a decimal seconds value, which may
   include a decimal point.  It is RECOMMENDED that systems support
   millisecond precision for this parameter.  The LCS MUST LIS SHOULD provide the
   most accurate LI that can be determined within the specified interval.  This parameter could be used interval
   for the specific service.

   The LIS MAY use the value of the "responseTime" attribute as input
   when selecting the method of location determination, where multiple
   such methods exist.  If this parameter is absent, then the LCS LIS MUST
   return the most precise LI it is capable of determining.

7.2.

6.2.  "locationType" Parameter

   The "locationType" element is MAY be included in a location request. request
   message.  It contains a list of LI types that are requested by the
   Device.  The following list describes the possible values:
   any:  The LCS LIS SHOULD attempt to provide LI in all forms available to
      it.  This value MUST be assumed as the default if no
      "locationType" is specified.  The LCS LIS SHOULD return location
      information in a form that is suited for routing and responding to
      an emergency call in its jurisdiction.  The LCS LIS MAY alternatively
      or additionally return a location URI.
   geodetic:  The LCS LIS SHOULD return a geodetic location for the Target.
   civic:  The LCS LIS SHOULD return a civic address for the Target.  Any
      type of civic address may be returned.  The LCS SHOULD ignore this
      value if a request for jurisdictional or postal civic address has
      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 LIS SHOULD return a location URI for the Target.

   The LCS LIS SHOULD return the requested location type or types.  The LCS LIS
   MAY provide additional location types, or it MAY provide alternative
   types if the request cannot be satisfied for a requested location
   type.  If the "exact" attribute is present and set to "true" in a
   location request, then a successful LCS LIS response MUST provide the
   requested location type only, with no additional location
   information.  The "exact" attribute has no effect when this element
   is set to "any".

   The "SHOULD"-strength requirement on this parameter is included to
   allow for soft-failover.  This enables a fixed client configuration
   that prefers a specific location type without causing location
   requests to fail when that location type is unavailable.  Unless the
   "exact" attribute is set, the LCS LIS MUST provide LI in any available
   form if it is unable to comply with the request.

   For example, a notebook computer could be configured to retrieve
   civic addresses, which is usually available from typical home or work
   situations.  However, when using a wireless modem, the LCS LIS might be
   unable to provide a civic address and thus provides a geodetic
   address.

7.2.1.

6.2.1.  "exact" Attribute

   When the "exact" attribute is set to "true", it indicates to the LCS LIS
   that the contents of the "locationType" parameter MUST be strictly
   followed.  The default value of "false" allows the LCS LIS the option of
   returning something beyond what is specified, such as a location URI
   when only a civic location was requested.

   A value of "true" indicates that the LCS LIS MUST provide a location of
   the requested type or types or MUST provide an error.  The LCS LIS MUST
   provide the requested types only and these types SHOULD be specified
   in the same order as they were requested. only.  The LCS SHOULD LIS MUST handle an exact
   request that includes a "locationType" element set to "any" as if the
   "exact" attribute were set to "false".

7.3.

6.3.  "code" Parameter

   All "error" responses MUST contain a response code.  The "code" attribute
   applies to the "error" and "locationResponse" messages.  All errors are
   application-level errors, and MUST only be provided in successfully
   processed transport-level responses.  For example where HTTP is used
   as the transport, HELD error messages MUST be accompanied by a 200 OK
   HTTP response.

   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
      in some fashion.
   xmlError:  This code indicates that the XML content of the request
      was either badly formed or invalid.
   generalLcsError:
   generalLisError:  This code indicates that an unspecified error
      occurred at the LCS. LIS.
   locationUnknown:  This code indicates that the LCS LIS could not
      determine the location of the Device.
   unsupportedMessage:  This code indicates that the request was not
      supported or understood by the LCS. LIS.
   timeout:  This code indicates that the LCS LIS could not satisfy the
      request within the time specified in the "responseTime" parameter.
   cannotProvideLiType:  This code indicates that the LCS LIS was unable to
      provide LI of the type or types requested.  This code is used when
      the "exact" attribute on the "locationType" parameter is set to
      "true".

7.4.

6.4.  "message" Parameter

   The "locationResponse" and "error" messages message MAY include a "message" attribute to convey some
   additional, human-readable information about the result of the
   request.  This message MAY be included in any language, which SHOULD
   be indicated by the "xml:lang", attribute.  The default language is
   assumed to be English.

7.5.

6.5.  "locationURI" Parameter

   The "locationURI" element includes a single Location URI.  Each
   Location URI that is allocated by the LCS LIS is unique to the device
   that is requesting it.

   A "locationResponse" message MAY contain any number of "locationURI"
   elements.  It is RECOMMENDED that the LCS LIS allocate a Location URI for
   each scheme that it supports and that each scheme is present only
   once.  URI schemes and their secure variants such as http and https
   should
   MUST be regarded as two separate schemes.

7.5.1.

6.5.1.  "expires" Parameter

   The "expires" attribute indicates the time at which the Location URI
   provided by the LCS LIS will expire.  This attribute is included in the
   "locationResponse" message only.

   Responses to Locations requests for Location URIs MUST include the
   expiry time of the Location URI.

8.

7.  XML Schema

   This section gives the XML Schema Definition [12] of the
   "application/held+xml" format.  This is presented as a formal
   definition of the "application/held+xml" format.  Note that the XML
   Schema definition is not intended to be used with on-the-fly
   validation of the presence XML document.

  <?xml version="1.0"?>
  <xs:schema
      targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
      xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
      xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
      xmlns:cp="urn:ietf:params:xml:ns:common-policy"
      xmlns:gml="http://www.opengis.net/gml"
      xmlns:xml="http://www.w3.org/XML/1998/namespace"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

    <xs:annotation>
      <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> source="https://www.ietf.org/rfc/rfcXXXX.txt">
  <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
         published RFC and remove this note.]] -->
        This document defines HELD messages.
      </xs:documentation>
    </xs:annotation>

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
               schemaLocation="xml.xsd"/>
    <xs:import namespace="urn:ietf:params:xml:ns:pidf:geopriv10"
               schemaLocation="geopriv10.xsd"/>
    <xs:import
        namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        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"
               schemaLocation="GML-3.1.1/base/geometryBasic2d.xsd"/>

    <!-- Return Location -->
    <xs:complexType name="returnLocationType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="locationURI" type="xs:anyURI"
                        maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="expires" type="xs:dateTime"
                        use="required"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <!-- Duration responseTime Type -->
    <xs:simpleType name="durationType"> 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:minInclusive value="0.0"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
    </xs:simpleType>

    <!-- Location Type -->
    <xs:simpleType name="locationTypeBase">
      <xs:union>
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="any"/>
          </xs:restriction>
        </xs:simpleType>
        <xs:simpleType>
          <xs:list>
            <xs:simpleType>
              <xs:restriction base="xs:token">
                <xs:enumeration value="civic"/>
                <xs:enumeration value="geodetic"/>
                <xs:enumeration value="postalCivic"/>
                 <xs:enumeration value="jurisdictionalCivic"/>
                 <xs:enumeration value="locationURI"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:list>
        </xs:simpleType>
      </xs:union>
    </xs:simpleType>

     <xs:complexType name="locationTypeType">
      <xs:simpleContent>
        <xs:extension base="held:locationTypeBase">
          <xs:attribute name="exact" type="xs:boolean"
                        use="optional" default="false"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

    <!-- Response code -->
    <xs:simpleType name="codeType">
      <xs:restriction base="xs:token">
             <xs:enumeration value="success"/>
              <xs:enumeration value="requestError"/>
             <xs:enumeration value="xmlError"/>
             <xs:enumeration value="generalLcsError"/> value="generalLisError"/>
             <xs:enumeration value="locationUnknown"/>
             <xs:enumeration value="unsupportedMessage"/>
             <xs:enumeration value="timeout"/>
             <xs:enumeration value="cannotProvideLiType"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- Message Definitions -->
    <xs:complexType name="baseRequestType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence/>
          <xs:attribute name="responseTime" type="held:durationType" type="held:responseTimeType"
                        use="optional"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:complexType name="baseResponseType"> name="errorType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence/>
          <xs:attribute name="code" type="held:codeType"
                        use="required"/>
          <xs:attribute name="message" type="xs:token"
                        use="optional"/>
          <xs:attribute ref="xml:lang" use="optional"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:element name="error" type="held:baseResponseType"/>

   <!-- Location Response -->
     <xs:complexType name="locationResponseType">
       <xs:complexContent>
         <xs:extension base="held:baseResponseType">
           <xs:sequence>
             <xs:element name="locationUriSet"
                         type="held:returnLocationType"
                         minOccurs="0"/>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="locationResponse"
                 type="held:locationResponseType"/> type="held:errorType"/>

  <!-- 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> Location Response -->
    <xs:complexType name="locationResponseType">
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="locationUriSet"
                        type="held:returnLocationType"
                        minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

    <xs:element name="locationResponse"
                type="held:locationResponseType"/>

    <xs:complexType name="locationRequestType">
      <xs:complexContent>
        <xs:extension base="held:baseRequestType">
          <xs:sequence>
              <xs:element name="locationType"
                          type="held:locationTypeType"
                          minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>

    <xs:element name="locationRequest"
                type="held:locationRequestType"/>

  </xs:schema>

9.

8.  HTTP Binding

   This section defines an HTTP [3] binding for this protocol, which all
   conforming implementations MUST support.  This binding takes the form
   of a Web Service (WS) that can be described by the Web Services
   Description Language (WSDL) document in Section 9.1. 8.1.

   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
   "application/held+xml".

   The LCS LIS populates the HTTP headers so that they are consistent with
   the contents of the message.  In particular, the "expires" and cache
   control headers are used to control the caching of any PIDF-LO
   document or Location URIs.  The HTTP status code SHOULD have the same
   first digit as any "locationResponse" or "error" body included, and
   it SHOULD indicate a
   2xx series response when a PIDF-LO document or Location URI is
   included.

   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
   queries are received, the LCS LIS MUST attempt to provide either a
   PIDF-LO document or a Location URI, as if the request was a location
   request.

   This binding MUST use TLS as described in [4].  TLS provides message
   integrity and privacy between Device and LCS. LIS.  The LCS LIS MUST use the
   server authentication method described in [4]; the Device MUST fail a
   request if server authentication fails, except in the event of an
   emergency.

9.1.

8.1.  HTTP Binding WSDL

   The following WSDL 2.0 [27] [23] document describes the HTTP binding for
   this protocol.  Actual service instances MUST provide a "service"
   with at least one "endpoint" that implements the "heldHTTP" binding.
   A service description document MAY include this schema directly or by
   using the "import" or "include" directives.

       <?xml version="1.0"?>
       <wsdl:definitions
           xmlns:wsdl="http://www.w3.org/2005/05/wsdl"
           xmlns:whttp="http://www.w3.org/2005/05/wsdl/http"
           xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
           xmlns:pidf="urn:ietf:params:xml:ns:pidf"
           xmlns:heldhttp="urn:ietf:params:xml:ns:geopriv:held:http"
           targetNamespace="urn:ietf:params:xml:ns:geopriv:held:http"
           type="http://www.w3.org/2005/05/wsdl/http">
         <wsdl:documentation>
           This document describes the basic HELD sighting web service.
           Please refer to RFCXXXX for details.
       [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number
         for this specification and remove this note.]]
         </wsdl:documentation>

         <wsdl:types>
           <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
             <xsd:import namespace="urn:ietf:params:xml:ns:geopriv:held"
                         schemaLocation="held.xsd"/>
             <xsd:import namespace="urn:ietf:params:xml:ns:pidf"/>
           </xsd:schema>
         </wsdl:types>

         <wsdl:interface name="held">

           <wsdl:operation name="locationRequest" method="POST">
             <wsdl:input message="held:locationRequest"/>
             <wsdl:output message="held:locationResponse"/>
             <wsdl:fault message="held:error"/>
           </wsdl:operation>

           <wsdl:operation
               name="getLocation" method="GET"
               pattern="http://www.w3.org/2004/08/wsdl/out-only">
             <wsdl:output message="held:locationResponse"/>
             <wsdl:fault message="held:error"/>
           </wsdl:operation>

         </wsdl:interface>

       <!-- Note that the by default the HTTP binding uses:
               whttp:inputSerialization="application/xml"
               whttp:outputSerializatiom="application/xml"
               whttp:faultSerialization="application/xml"
               whttp:location=""
         -->

         <wsdl:binding name="heldHTTP" whttp:defaultMethod="POST">
            <wsdl:operation
                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:definitions>

10.

9.  Security Considerations

   The threat model for this protocol assumes that the LCS LIS exists within
   the same administrative domain as the Device.  The LCS LIS requires
   access to network information so that it can determine Location.
   Therefore, the LCS LIS can use network information to protect against a
   number of the possible attacks.

   Specific requirements and security considerations for location
   acquisition protocols are provided in [11] including that the LCP
   MUST NOT assume prior network access authentication, which is
   addressed in Section 10.2 9.2

   An in-depth discussion of the security considerations applicable to
   the use of Location URIs and by-reference provision of LI is included
   in [16].

10.1.

9.1.  Return Routability

   It is RECOMMENDED that Location Configuration Information Servers use return
   routability rather than requiring Device authentication.  Device
   authentication SHOULD NOT be required due to the administrative
   challenge of issuing and managing of client credentials, particularly
   when networks allow visiting users to attach devices.  However, the
   LCS
   LIS MAY require any form of authentication as long as these factors
   are considered.

   Addressing information used in a request to the LCS LIS is used to
   determine the identity of the Device, and to address a response.
   This ensures that a Device can only request its own LI.

   A temporary spoofing of IP address could mean that a device could
   request a Location URI that would result in another Device's
   location.  One or more of the follow approaches are RECOMMENDED to
   limit this exposure:
   o  Location URIs SHOULD have a limited lifetime, as reflected by the
      value for the expires element (Section 7.5.1). 6.5.1).
   o  The network SHOULD have mechanisms that protect against IP address
      spoofing.
   o  The LCS LIS SHOULD ensure that requests can only originate from within
      its administrative domain.
   o  The LCS LIS and network SHOULD be configured so that the LCS LIS is made
      aware of Device movement within the network and addressing
      changes.  If the LCS LIS detects a change in the network, then all
      location URIs MUST be invalidated.

   The above measures are dependent on network configuration and SHOULD
   be considered with circumstances in mind.  For instance, in a fixed
   internet access, providers may be able to restrict the allocation of
   IP addresses to a single physical line, ensuring that spoofing is not
   possible; in such an environment, other measures may not be
   necessary.

10.2.

9.2.  Transaction Layer Security

   All bindings for this protocol MUST ensure that messages are
   adequately protected against eavesdropping and modification.
   Bindings MUST also provide a means of authenticating the LCS. LIS.

   It is RECOMMENDED that all bindings also use TLS [2].

   For the HTTP binding, TLS MUST be used.  TLS provides protection
   against eavesdropping and modification.  The server authentication
   methods described in HTTP on TLS [4] MUST be used.

11.

10.  Examples

11.1.

10.1.  Simple HTTP Binding Example Messages

   The examples in this section show a complete HTTP message that
   includes the HELD request or response document.

   This example shows the most basic request for a LO.  This uses the
   GET feature described by the HTTP binding.  This example assumes that
   the LCS LIS service exists at the URL "https://lcs.example.com/location". "https://lis.example.com/location".

         GET /location HTTP/1.1
         Host: lcs.example.com lis.example.com
         Accept:application/held+xml,
             application/xml;q=0.8,
             text/xml;q=0.7
         Accept-Charset: UTF-8,*
   The GET request is exactly identical to a minimal POST request that
   includes an empty "locationRequest" element.

         POST /location HTTP/1.1
         Host: lcs.example.com lis.example.com
         Accept: application/held+xml,
             application/xml;q=0.8,
             text/xml;q=0.7
         Accept-Charset: UTF-8,*
         Content-Type: application/held+xml
         Content-Length: 87

         <?xml version="1.0"?>
         <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
   The successful response to either of these requests is a PIDF-LO
   document.  The following response shows a minimal PIDF-LO response.

         HTTP/1.x 200 OK
         Server: Example LCS LIS
         Date: Tue, 10 Jan 2006 03:42:29 GMT
         Expires: Tue, 10 Jan 2006 03:42:29 GMT
         Cache-control: private
         Content-Type: application/held+xml
         Content-Length: 594

         <?xml version="1.0"?>
         <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
                          code="success"
                          message="OK"> xmlns="urn:ietf:params:xml:ns:geopriv:held">
         <presence xmlns="urn:ietf:params:xml:ns:pidf"
                   entity="pres:3650n87934c@ls.example.com">
           <tuple id="3b650sf789nd">
           <status>
            <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
             <location-info>
                <Point xmlns="http://www.opengis.net/gml"
                       srsName="urn:ogc:def:crs:EPSG::4326">
                  <pos>-34.407 150.88001</pos>
                </Point>
              </location-info>
              <usage-rules>
                <retention-expiry>
                  2006-01-11T03:42:28+00:00</retention-expiry>
              </usage-rules>
            </geopriv>
           </status>
           <timestamp>2006-01-10T03:42:28+00:00</timestamp>
           </tuple>
         </presence>
         </locationResponse>
   The error response to either of these requests is an error document.
   The following response shows an example error response.

         HTTP/1.x 200 OK
         Server: Example LCS LIS
         Expires: Tue, 10 Jan 2006 03:49:20 GMT
         Cache-control: private
         Content-Type: application/held+xml
         Content-Length: 135

         <?xml version="1.0"?>
         <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
                code="locationUnknown"
                message="Unable to determine location"/>

   Note:  To focus on important portions of messages, all examples
      following this note do not show HTTP headers or the XML prologue.
      In addition, sections of XML not relevant to the example are
      replaced with comments.

11.2.

10.2.  Simple Location Request Example

   The location request shown below doesn't specify any location types
   or response time.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>

   The response to this location request is a list of Location URIs.

      <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
                             code="success" message="OK"> xmlns="urn:ietf:params:xml:ns:geopriv:held">
        <locationUriSet expires="2006-01-01T13:00:00">
          <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
          </locationURI>
          <locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
          </locationURI>
        </locationUriSet>
      </locationResponse>

   An error response to this location request is shown below:

         <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    code="locationUnknown"
                    message="Location not available"/>

11.3.

10.3.  Location Request Example for Multiple Location Types

   The following Location Request message includes a request for
   geodetic, jurisdictional civic and any Location URIs.

         <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
          <locationType exact="true">
            geodetic
            jurisdictionalCivic
            civic
            locationURI
          </locationType>
          </locationRequest>

   The corresponding Location Response message includes the requested
   location information, including two location URIs.

       <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
                                 code="success" message="OK"> xmlns="urn:ietf:params:xml:ns:geopriv:held">
          <locationUriSet expires="2006-01-01T13:00:00">
          <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
          </locationURI>
          <locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
          </locationURI>
         </locationUriSet>
         <presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
                entity="pres:ae3be8585902e2253ce2@10.102.23.9">
         <tuple id="lisLocation">
          <status>
          <geopriv>
           <location-info>
             <gs:Circle
              xmlns:gs="http://www.opengis.net/pidflo/1.0"
              xmlns:gml="http://www.opengis.net/gml"
              srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-34.407242 150.882518</gml:pos>
              <gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
              </gs:radius>
             </gs:Circle>
             <ca:civicAddress
              xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              xml:lang="en-au">
              <ca:country>AU</ca:country>
              <ca:A1>NSW</ca:A1>
              <ca:A3>Wollongong</ca:A3>
              <ca:A4>Gwynneville</ca:A4>
              <ca:STS>Northfield Avenue</ca:STS>
              <ca:LMK>University of Wollongong</ca:LMK>
              <ca:FLR>2</ca:FLR>
              <ca:NAM>Andrew Corporation</ca:NAM>
              <ca:PC>2500</ca:PC>
              <ca:BLD>39</ca:BLD>
              <ca:SEAT>WS-183</ca:SEAT>
              <ca:POBOX>U40</ca:POBOX>
             </ca:civicAddress>
           </location-info>
           <usage-rules>
             <retransmission-allowed>false</retransmission-allowed>
             <retention-expiry>2007-05-25T12:35:02+10:00
             </retention-expiry>
           </usage-rules>
           <method>Wiremap</method>
           </geopriv>
          </status>
          <timestamp>2007-05-24T12:35:02+10:00</timestamp>
        </tuple>
        </presence>
       </locationResponse>

11.4.

10.4.  Sample LCS LIS  WSDL Document

   The following WSDL document demonstrates how a WSDL document can be
   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"?>
   <wsdl:definitions
       xmlns:wsdl="http://www.w3.org/2005/05/wsdl"
       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
         namespace="urn:ietf:params:xml:ns:geopriv:held:http"/>

     <wsdl:service name="sample-held-svc" interface="heldhttp:held">
       <wsdl:endpoint name="sample-held-ep"
                      binding="heldhttp:heldHTTP"
                      address="https://lcs.example.com/location"/>
                      address="https://lis.example.com/location"/>
     </wsdl:service>

   </wsdl:definitions>

12.

11.  IANA Considerations

   This document registers an XML namespace and schema and the
   "application/held+xml" MIME type.

12.1.

11.1.  URN Sub-Namespace Registration for
       urn:ietf:params:xml:ns:geopriv:held

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6].
      URI: urn:ietf:params:xml:ns:geopriv:held
      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>HELD Messages</title>
             </head>
             <body>
               <h1>Namespace for HELD Messages</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:held</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

12.2.

11.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in [6].
   URI:  urn:ietf:params:xml:schema:geopriv:held
   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Mary Barnes (mary.barnes@nortel.com).
   Schema:  The XML for this schema can be found as the entirety of
      Section 8 7 of this document.

12.3.

11.3.  URN Sub-Namespace Registration for
       urn:ietf:params:xml:ns:geopriv:held:http

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in
   [6].

      URI: urn:ietf:params:xml:ns:geopriv:held:http
      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
      XML:

         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
             <head>
               <title>HELD HTTP Binding WS</title>
             </head>
             <body>
               <h1>Namespace for HELD HTTP Binding WS</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:held:http</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

12.4.

11.4.  MIME Media Type Registration for 'application/held+xml'

   This section registers the "application/held+xml" MIME type.
   To:  ietf-types@iana.org
   Subject:  Registration of MIME media type application/held+xml
   MIME media type name:  application
   MIME subtype name:  held+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [20], [19], section 3.2.
   Security considerations:  This content type is designed to carry
      protocol data related to the location of an entity, which could
      include information that is considered private.  Appropriate
      precautions should be taken to limit disclosure of this
      information.
   Interoperability considerations:  This content type provides a basis
      for a protocol
   Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]
   Applications which use this media type:  Location information
      providers and consumers.
   Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:  Mary
      Barnes <mary.barnes@nortel.com>
   Intended usage:  LIMITED USE
   Author/Change controller:  This specification is TBD
   Other information:  This media type is a specialization of
      application/xml [20], [19], and many of the considerations described
      there also apply to application/held+xml.

13.

12.  Contributors

   James Winterbottom, Martin Thomson and Barbara Stark are the authors
   of the original document, from which this WG document was derived.
   Their contact information is included in the Author's address
   section.  James Winterbottom  In addition, they also contributed to the WG document.

14. document, in
   particular the schema and WSDL.

13.  Acknowledgements

   The author/contributors would like to thank the following people for
   their constructive input to this document (in alphabetical order):
   Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome
   Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk,
   Carl Reed, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
   Shrum, and Hannes Tschofenig.

15.

14.  Changes since last Version

   NOTE TO THE RFC-Editor: Please remove this section prior to
   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:

   1) heldResponse renamed to locationResponse.

   2) Changed namespace references for the PIDF-LO geoShape in the
   schema to match the agreed GML PIDF-LO Geometry Shape Application
   Schema.

   3) Removed "options" element - leaving optionality/extensibility to
   XML mechanisms.

   4) Changed error codes to be enumerations and not redefinitions of
   HTTP response codes.

   5) Updated schema/examples for the above and removed some remnants of
   the context element.

   6) Clarified the definition of "Location Information (LI)" to include
   a reference to the location (to match the XML schema and provide
   consistency of usage throughout the document).  Added an additional
   statement in section 7.2 (locationType) to clarify that LCS MAY also
   return a Location URI.

   7) Modifed the definition of "Location Configuration Server (LCS)" to
   be consistent with the current definiton in the requirements
   document.

   8) Updated Location Response (section 6.3) to remove reference to
   context and discuss the used of a local identifier or unlinked
   pseudonym in providing privacy/security.

   9) Clarified that the source IP address in the request is used as the
   identifier for the target/device for the HELD protocol as defined in
   this document.

   10) Miscellaneous editorial clarifications.

16.

15.  References

16.1.

15.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [3]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [4]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [5]   Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
         Language) XML-Signature Syntax and Processing", RFC 3275,
         March 2002.

   [6]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [7]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
         Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [8]   Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [9]   Thomson, M. and J. Winterbottom, "Revised Civic Location Format
         for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
         progress), February 2007.

   [10]  Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
         Considerations and Recommendations",
         draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
         July 2007.

   [11]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
         Configuration Protocol; Problem Statement and  Requirements",
         draft-ietf-geopriv-l7-lcp-ps-02
         draft-ietf-geopriv-l7-lcp-ps-05 (work in progress), April
         September 2007.

   [12]  Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML
         Schema Part 1: Structures Second Edition", World Wide Web
         Consortium Recommendation REC-xmlschema-1-20041028,
         October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [13]  Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
         Edition", World Wide Web Consortium Recommendation REC-
         xmlschema-2-20041028, October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

   [14]  Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
         "Geographic information - Geography Markup Language (GML)",
         OpenGIS 03-105r1, April 2004,
         <http://portal.opengeospatial.org/files/?artifact_id=4700>.

   [15]  Thomson, M. and J. Winterbottom, "Discovering the Local
         Location Information Server (LIS)",
         draft-thomson-geopriv-lis-discovery-00
         draft-thomson-geopriv-lis-discovery-03 (work in progress),
         February
         September 2007.

   [16]  Marshall, R., "Requirements for a Location-by-Reference
         Mechanism used in Location  Configuration and Conveyance",
         draft-marshall-geopriv-lbyr-requirements-01 Location-by-Reference
         Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work in
         progress),
         March September 2007.

16.2.

15.2.  Informative References

   [17]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
         September 1981.

   [18]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [19]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

   [20]

   [19]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [21]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
         RFC 3080, March 2001.

   [22]

   [20]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [23]

   [21]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

   [24]

   [22]  Polk, J. and B. Rosen, "Session "Location Conveyance for the Session
         Initiation Protocol Location
         Conveyance", draft-ietf-sip-location-conveyance-07 Protocol", draft-ietf-sip-location-conveyance-08
         (work in progress), February 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]

   [23]  Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web
         Services Description Language (WSDL) Version 2.0 Part 1: Core
         Language", W3C CR CR-wsdl20-20060106, January 2006.

Appendix A.  HELD Compliance to IETF LCP requirements

   This appendix describes HELD's compliance to the requirements
   specified in the [11].

A.1.  L7-1: Identifier Choice

   "The LIS L7 LCP MUST be presented with a unique able to carry different identifiers or MUST
   define an identifier of its own
   addressing that is mandatory to implement.  Regarding the
   latter aspect, such an identifier is only appropriate if it is from
   the same realm associated in some way with as the physical location of one for which the end host." location information service
   maintains identifier to location mapping."

   COMPLY

   HELD uses the IP address of the location request message as the
   primary source of identity for the requesting device or target.  This
   identity can be used with other contextual network information to
   provide a physical location for the Target for many network
   deployments.  There may be network deployments where an IP address
   alone is insufficient to identify a Target in a network.  However,
   any necessary identity extensions for these networks is beyond the
   scope of this document.

A.2.  L7-2: Mobility Support

   "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
   broad range of mobility from devices that can only move between
   reboots, to devices that can change attachment points with the impact
   that their IP address is changed, to devices that do not change their
   IP address while roaming, to devices that continuously move by being
   attached to the same network attachment point."

   COMPLY

   Mobility support is inherently a characteristic of the access network
   technology and HELD is designed to be access network agnostic.
   Consequently HELD complies with this requirement.  In addition HELD
   provides specific support for mobile environments by providing an
   optional responseTime attribute in location request messages.
   Wireless networks often have several different mechanisms at their
   disposal for position determination (e.g.  Assisted GPS versus
   location based on serving base station identity), each providing
   different degrees of accuracy and taking different amounts of time to
   yield a result.  The responseTime parameter provides the LIS with a
   criterion which it can use to select a location determination
   technique.

A.3.  L7-3: Layer 7 ASP and Layer 2/3 Access Network Provider Relationship

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST NOT assume a business or trust
   relationship between the provider
   of application layer (e.g., SIP, XMPP, H.323) provider Application Service Provider (ASP) and the access
   network provider operating the LIS."
   Access Network Provider.  Requirements for resolving a reference to
   location information are not discussed in this document."

   COMPLY

   HELD describes a location acquisition protocol and has no
   dependencies on how location is used once it has been acquired. the business or trust relationship between the ASP
   and the Access Network Provider.  Location acquisition using HELD is
   subject to the restrictions described in Section 10. 9.

A.4.  L7-4: Layer 2 and Layer 3 Provider Relationship

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol
   MUST assume that there is a trust and business relationship between
   the L2 and the L3 provider.  The L3 provider operates the LIS and
   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
   same host are different entities, they cooperate for the purposes
   needed to determine end system locations."

   COMPLY

   HELD was specifically designed with this model in mind and readily
   allows itself to chaining requests between operators without a change
   in protocol being required.  HELD is a webservices protocol it can be
   bound to transports other than HTTP, such as BEEP. HTTP.  Using a transport
   like BEEP for HELD o offers the option of
   high request throughput over a dedicated connection between an L3
   provider and an L2 provider without incurring the serial restriction
   imposed by HTTP.  This is less easy to do with protocols that do not
   decouple themselves from the transport.

A.5.  L7-5: Legacy Device Considerations

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol
   MUST consider legacy residential NAT devices and NTEs in an DSL
   environment that cannot be upgraded to support additional protocols,
   for example to pass additional information through DHCP."

   COMPLY

   HELD is an application protocol and operates on top of IP.  A HELD
   request from a host behind a residential NAT will traverse the NAT
   acquiring the external address of the home router.  The location
   provided to the host therefore will be the address of the home router
   in this circumstance.  No changes are required to the home router in
   order to support this function, HELD was designed specifically to
   address this deployment scenario.

A.6.  L7-6: VPN Awareness

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol
   MUST assume that at least one end of a VPN is aware of the VPN
   functionality.  In an enterprise scenario, the enterprise side will
   provide the LIS used by the client and can thereby detect whether the
   LIS request was initiated through a VPN tunnel."

   COMPLY

   HELD does not preclude a LIS on the far end of a VPN tunnel being
   aware that the client request is occurring over that tunnel.  It also
   does not preclude a client device from accessing a LIS serving the
   local physical network and subsequently using the location
   information with an application that is accessed over a VPN tunnel.

A.7.  L7-7: Network Access Authentication

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol
   MUST NOT assume prior network access authentication."

   COMPLY

   HELD makes no assumptions about prior network access authentication.
   HELD strongly recommends the use of TLS with server-side certificates
   for communication between the end-point and the LIS.  There is no
   requirement for the end-point to authenticate with the LIS.

A.8.  L7-8: Network Topology Unawareness

   "The design of the GEOPRIV Layer 7 Location Configuration Protocol
   MUST NOT assume end systems being aware of the access network
   topology.  End systems are, however, able to determine their public
   IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
   COMPLY

   HELD makes no assumption about the network topology.  HELD doesn't
   require that the device know its external IP address, except where
   that is required for discovery of the LCS. LIS.

A.9.  L7-9: Discovery Mechanism

   "The L7 LCP MUST define a single mandatory to implement discovery
   mechanism."

   COMPLY

   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

   Mary Barnes (editor)
   Nortel
   2201 Lakeside Blvd
   Richardson, TX

   Email: mary.barnes@nortel.com
   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/

   Barbara Stark
   BellSouth
   Room 7A41
   725 W Peachtree St.
   Atlanta, GA  30308
   US

   Email: barbara.stark@bellsouth.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).