Geopriv                                                  J. Winterbottom
Internet-Draft                                        Andrew Corporation
Intended status: Standards Track                           June 22, 2007                           H. Tschofenig
Expires: December 24, April 8, 2008                            Nokia Siemens Networks
                                                              M. Thomson
                                                      Andrew Corporation
                                                         October 6, 2007

              HELD Protocol Context Management Extensions
             draft-winterbottom-geopriv-held-context-00.txt
             draft-winterbottom-geopriv-held-context-01.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 December 24, 2007. April 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a protocol extension for HELD enabling an
   End-Point the HTTP Enabled
   Location Delivery (HELD) protocol.  It allows a Target to manage stateful
   their location information on an LCS. a Location Information Server (LIS)
   through the application of constraints invoked by accessing a
   location URI.  Constraints described in this memo restrict how often
   location can be accessed through a location URI, how long the URI is
   valid for, and the type of location information returned when a
   location URI is accessed.  Extension points are also provided.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Detailed Description  What is a Context? . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Constraints  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Limited Use URIs . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Snapshot URIs  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Location URI and id Generation Rules Type URIs . . . . . . . . . . . . .  9 . . . . . . .  7
   5.  XML Schema  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Create Context Message . . . . . . . . . . . . . . . . . .  8
     5.2.  Update Context Message . . . . . . . . . . . . . . . . . .  9
     5.3.  Context Response Message . . . . . . . . . . . . . . . . . 10
   6.  Guidelines For Defining
     5.4.  Context Data Extensions Error Messages . . . . . . . . . . . . . . . . . . 12
     5.5.  Location URI and Context Identifier Generation Rules . . . 12
   6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15 19
     8.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:context  . . . . . . . 15 19
     8.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 15 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 21
   Appendix A.  Context Extensions  . . . . . . . . . . . . . . . . . 22
   Appendix B.  HELD Compliance to IETF Location Configuration
                Protocol Location Reference Requirements  . . . . . . 24
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Author's Address . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 20 28

1.  Introduction

   The HELD HTTP Enabled Location Delivery (HELD) protocol specification
   [I-D.ietf-geopriv-http-location-delivery] provides a set of features
   that can be used by an End-Point a Target to retrieve location information from an LCS. a
   Location Information Server (LIS).  The basic HELD specification does
   this in a more or less stateless manner.  There
   are situations however, where the End-Point wants or requires
   explicit management of data in manner, and when a stateful manner on the LCS.  This
   specification describes an extension to location URI is
   retrieved the HELD protocol to support
   End-Point management Target has no way of state information contained in a "context" on controlling how the LCS.

   Information contained in a context relates to URI is used; a specific End-Point.
   One of the most critical pieces of functionality provided
   Location Recipient in this
   specification is pocession of the ability to void a location URI.  This is
   important, because without this functionality there is no way stop a
   third-party that has your location URI from obtaining your location.
   This condition will persist until can get the
   Target's location until the URI expires.  The
   extension defined  This basic mechanism may be
   reasonable in this specification changes this behaviour by
   providing the End-Point the means to create, update, and terminate a
   context on the LCS to which a specific location URI limited set is bound.
   Terminating the context therefore explicitly voids the location URI
   ending the ability of applications, but is unacceptable in a third-party to locate the Target.

   In addition to context management constructs this document also
   provides a set
   broader range of guidelines applications.  This position is highlighted in
   [I-D.ietf-geopriv-lbyr-requirements] which describes requirements for
   constraints relating to be followed by designers of future
   context data extensions. location URIs.  This specification provides
   support for these requirements in HELD.

2.  Terminology

   The key conventions words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and terminology used "OPTIONAL" in this
   document are defined to be interpreted as follows: described in [RFC2119].

   This document reuses the terms Target, as defined in [RFC3693].

   This document uses the term Location Configuration Server, LCS, Information Server (LIS) as the
   node in the access network providing that provides location information to an
   end-point. about a
   Target.  This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].

   This document uses the term End-Point to refer

3.  What is a Context?

   A Location URI points to the device or host
   requesting a LIS that is able to which contextual information stored on provide the LCS applies. location
   of a specific Target.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are LIS is able to be interpreted as described in [RFC2119].

3.  Detailed Description

   An End-Device wishing map the URI to have the location
   of the Target inside its administrative domain.  We call this mapping
   a "context".  In the basic HELD specification the context is
   implicitly created on with the LCS includes request for a
   <createContext> element location URI in the <locationRequest>.  Information that
   locationRequest message.  The Target has no control of the End-Point wants in mapping
   from the URI to the Target's location.  This specification provides a
   degree of control to the Target, allowing it to specify rules to the
   LIS on how a context should map a URI to location information.

   A context expires when it reaches a certain age, at which time the
   mapping between the URI and the Target's location ceases.  In the
   basic HELD specification the exiry time of the context is included inside determined
   by the
   <createContext> element.  Extensibility LIS when the Target requests a location URI.  By allowing the
   Target to specify and change the life time of a context scheme the Target is
   provided
   able to allow additional elements create URIs for limited periods, or to added terminate URIs for
   which it longer wishes its location to be returned.  This
   specification provides explicit support for this functionality.

4.  Constraints

   Constraints restrict the context easily. ability of a Location Recipient to resolve a
   location URI to location information.  The general idea is shown in Figure 1.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
     <locationType>locationURI</locationType>
     <hcx:createContext
             hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
             hcx:lifeTime="7200">
       <ex1:extension-1
             ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1">
         <ex1:value>7200</ex1:value>
       </ex1:extension-1>
       <extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>
       <extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>
       .
       .
       .
       <extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>
     </hcx:createContext>
   </locationRequest>

                       Figure 1: createContext Usage

   An LCS constraints are selected
   by the Target and they are provided to the LIS that understands maintains them
   along with the context.  A LIS, understanding this new element SHALL include specification,
   receives constraints provided by the Target, and returns a
   <contextResponse> element in set of
   URIs influenced by the corresponding heldRepsonse message.
   An LCS that does not understand this new element MUST ignore constraints.

   A single Target may want to place different contraints on different
   references and hence may have multiple contexts on the
   element as per [I-D.ietf-geopriv-http-location-delivery]. LIS.  The End-
   Point
   constraints describe what actions the LIS MUST assume that take when a URI
   associated with the LCS does not understand context related
   messages if it does not is accessed.  This document describes
   three basic constraints that a Target can use in comination for the
   same context.  Once set, these rules remain in force of the life of
   the context.

4.1.  Limited Use URIs

   A limited use URI can only be accessed a fixed number of times to
   yield the location of the Target.  Each time the URI is used to
   provide the location of the Target one usage is consumed.  Once the
   limit is reached the URI no longer yields the location of the Target
   and the URI is deemed spent.

   By setting the usage limit to 1, the Target is able to create a one-
   time-URI permitting a Location Recipient to obtain the Target's
   location only once.  Setting the usage limit to something higher than
   1 creates functionality analogous to a <contextResponse> element metro-ticket, where a Location
   Recipient in possession of the URI can access the Target's location
   many more times, but not exceeding the imposed limit.

   Not setting a usage limit provides similar semantics to the URI in
   the
   <heldResponse> message when base HELD specification, enabling a Location Recipient to
   continually obtain the Target's location until the URI expires due to
   age.

   When an HTTP URI is assigned to a context, the limit is the number of
   times that the URI can be accessed before the LIS returns an error.
   In the case of SIP it is the number of NOTIFY messages that are sent
   prior to the LIS returning an error.  Where a context was requested.  Since supports both
   SIP and HTTP URIs it is
   impossible the combination of URI accesses and NOTIFY
   messages that constitutes the usage value, each time the Target's
   location is provided constitutes a usage.

4.2.  Snapshot URIs

   A snapshot URI points to predict the location of the Target at a specific
   point in advance which elements time, and extensions no matter how many times the
   LCS URI is accessed it
   will understand before sending them, a mechanism always yield the same location.  This is useful if, for example,
   the LCS Target does not want to
   tell be tracked.  In this specification the End-Point
   location snapshot to which elements were understood and used a snapshot URIs points is
   required by each captured when
   the context data extension.  Guidelines for defining is created on the LIS.

4.3.  Location Type URIs

   A location type URI controls the form of location that can be
   accessed; This may be geodetic, civic, or both.

5.  Protocol Details

   This specification introduces four new HELD messages, create context data extensions
   (<createContext>), update context (<updateContext>), context response
   (<contextResponse>), and context error (<contextError>).  A LIS that
   does not understand this specification is expected to return a HELD
   _unsupportedMessage_ error code in a HELD error message.

   The specification assumes that the LIS was discovered as part of the
   general HELD LIS discovery process.  All messages are provided sent using the
   application/held+xml MIME type as defined in Section 6.

   An LCS supporting
   [I-D.ietf-geopriv-http-location-delivery].

5.1.  Create Context Message

   The Target creates a context on the LIS using a create context
   message.  The basic create context message supports the behaviour constraints
   described in Section 4 and consist of three attributes and one
   element described below:

   o  "uses": an optional attribute instructing the previous section LIS on how many
      times a URI may
   respond to yield the locationRequest location of Figure 1 with the Target.  This is a response similar
      positive integer, and has a default value of _unlimited_.  The LIS
      SHOULD support the Target specifying up to
   Figure 2.

<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
              code="200" message="OK">

  <locationUriSet expires="2007-08-01T13:00:00">
    <locationURI>
         https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
    </locationURI>
    <locationURI>
         sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
    </locationURI>
  </locationUriSet>

  <hcx:contextResponse
          hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
          hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
    <ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"
                  ex1:response="OK"/>
    <ex2:extension-2 ex2:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"
                  ex2:response="OK"/>

    <ex3:extension-3
         ex3:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3">
      <ex3:datum-3>data</ex3:datum-3>
      <ex3:stuff>guff in here for extension</ex3:stuff>
    </ex3:extension-3>

  </hcx:contextRresponse>

</heldResponse>

                  Figure 2: LCS response at least 100 uses.

   o  "snapshot": an optional attribute instructing the LIS to createContext

   The End-Point can update information associated take a
      snapshot of the Target's location for use with the context.  This
      a context by
   sending boolean value and has a default of _false_ meaning that a
      snapshot is not taken, and the Target's location is determined
      each time the URI is accessed.

   o  "locationType": an <updateContext> element in optional attribute instructing the LIS on the
      form of location that URI MUST provide.  This is an enumeration
      and may have a locationRequest message,
   along with value of _geodetic_, _civic_, or _any_.  If
      unspecified by the data Target the LIS will use a value of _any_.  If
      the Target specifies a location type that it wants changed in its context.  Elements
   previously provided to the LCS but not included LIS cannot provide,
      then the LIS MUST fail the context creation.

   o  "lifeTime": is a mandatory element that defines the maximum period
      in seconds that the
   <updateContext> data set SHALL remain unchanged. LIS should keep the context for.  The End-Point LIS MAY
      create the context with a shorter life time than was requested,
      but the life time MUST
   include NOT be longer than was requested.

   <hc:createContext
        xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
        uses="10"
        snapshot="false"
        locationType="any">
     <hc:lifeTime>7200</hc:lifeTime>
   </hc:createContext>

                      Figure 1: createContext Example

   Figure 1 shows a create context message defining a context which:

   o  may be accessed 10 times

   o  will determine the "id" attribute that it received as part location of the
   <contextResponse> with any <updateContext> Target each time it is accessed

   o  will return the location in either geodetic or civic form
      depending on the request tot he URI

   o  will be valid for 2 hours from the time of context creation

5.2.  Update Context Message

   A Target can change the life time of a context using an update
   context message.  As stated in Section 4 the three attributes used in
   the context creation, "uses", "snapshot", and "locationType" cannot
   be changed once a context is created.

   Since the Target may have more than one context on the LIS, the
   Target needs to clearly identify the changing context to be updated.  It does this by
   including a context identifier that is provided to it by the LCS.  This LIS when
   the context is important because created.

   <hc:updateContext
       xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
       hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
     <lifeTime>3600</lifeTime>
   </hc:updateContext>

             Figure 2: updateContext Life Time Change Example

   When a Target includes a life time element in some circumstances an End-Point may be behind update context
   message, the LIS needs to calculate a firewall or NAT so new context expiry time.  The
   LIS MUST do this by adding the LCS can't distinguish new life time value to the End-Point creating current
   time on the context from
   other devices behind LIS.  This mechanism means the same NAT.  The "id" makes Target can terminate a
   context at any time.  It does this distinction
   possible.

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

     <hcx:updateContext
             hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
            hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
       <ex1:extension-1
            ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1">
         <ex1:value>3600</ex1:value>
       </ex1:extension-1>
     </hcx:updateContext>

   </locationRequest>

                       Figure 3: updateContext Usage

   In by updating the example shown context with a
   life time of 0, which results in Figure 3 the End-Point is updating LIS setting the context created in Figure 1 so that expiry
   time to the present.  The LIS MAY also terminate a context if the
   life time value associated with
   extensions-1 will be is set to 3600 rather then less than 10 seconds.

   <hc:updateContext
       xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
       hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
     <lifeTime>0</lifeTime>
   </lhc:updateContext>

                Figure 3: updateContext Termination Example

5.3.  Context Response Message

   The LIS informs the previous value Target about the outcome of
   7200. context operations
   through the context response message.  The LIS MUST always send a
   context response from the LCS is shown message to a Target in Figure 4.

<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
              code="200" message="OK">

  <locationUriSet expires="2007-08-01T13:00:00">
    <locationURI>
        https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
    </locationURI>
    <locationURI>
        sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
    </locationURI>
  </locationUriSet>

  <hcx:contextResponse
          hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
          hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">
    <ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"
                  ex1:response="OK"/>
  </hcx:contextRresponse>

</heldResponse>

                  Figure 4: LCS response to updateContext a create context
   or update context message when the outcome was successful.  The End-Point MUST include
   context response message contains a locationType of locationURI in "code" attribute indicating the
   performed operation, and the
   locationRequest, other location attributes and elements indicating
   the state of the context.

   The "code" attribute is an enumerated type MAY also be present. and has one of the
   following values:

   o  _created_: The LCS
   SHALL return context was successfully created.

   o  _destroyed_: The context was destroyed.

   o  _updated_: The context was successfully updated.

   The following list details the same location URI set other attributes are may be returned
   in a context response message.

   id:  The identifier allocated to an
   <updateContext> as the context by the LIS.  This
      identifier is unique in the scope of the LIS.  The Target MUST
      keep this secret and MUST included it did for a <createContext>. in all update requests.  The LCS SHALL
      LIS MUST return the same and "id" as was used in all context response messages.

   uses:  The number of times that the request. context will yield the Target's
      location.  The End-Point LIS MAY include report either the "lifeTime" in an <updateContext>
   request if it wishes original value, or the
      number of remaining uses.  The LIS MUST report this value for all
      responses pertaining to alter a known and valid context.  This value MAY
      be ommitted when indicating that a context has been destroyed.

   snapshot:  The value of the lifetime snapshot attribute in the context.  The
      LIS MUST report this value for all responses pertaining to a known
      and valid context.  This value MAY be ommitted when indicating
      that a context has been destroyed.

   locationType:  The type of location information that can be acquired
      through URIs addressing the context.  Any
   change  The LIS MUST report this
      value for all responses pertaining to lifetime SHALL a known and valid context.
      This value MAY be reflected in omitted when indicating that a context has been
      destroyed.

   expiry:  The time at which the expires context will expire.  After this time,
      all location URIs that reference this context no longer work.  The
      LIS MUST report this value for all responses pertaining to a known
      context.  This attribute MUST be provided even when a "code" value
      of _destroyed_ is included in the
   returned <locationUriSet>.  If context repsonse message.

   In addition to the "lifeTime" attribute is above attributes, the LIS also provides a set of
   URIs that can used to
   zero or is negative then access the Target's location with the surety
   that the context SHALL expire immediately, and an
   empty <heldResponse> message SHALL constraints will be applied.  A URI set is returned with
   whenever a "code" context is successfully created on the LIS, and this set
   remains unchanged for the lifetime of 200.
   When a the context.  A context expires
   response message sent in reply to the LCS SHALL, immediately, delete all
   information associated with create context message in
   Figure 1 might look like Figure 4.

   <hc:contextResponse
             xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
             code="created"
             id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
             uses="10"
             snapshot="false"
             locationType="any"
             expires="2007-11-01T13:30:00">
       <hc:locationUriSet>
         <hc:locationURI>
            https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
         </hc:locationURI>
         <hc:locationURI>
            sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
         </hc:locationURI>
       </hc:locationUriSet>
   </hc:contextResponse>

                     Figure 4: contextResponse Example

5.4.  Context Error Messages

   When the LIS unable to perform the requested context and void all location URIs
   associated with operation it
   need to inform the context.

   An <updateContext> request containing Target of this.  It does this using a context
   error message.  The context error message consists of a "errorCode"
   and an "id" that is not recognized
   by optional "message" attribute.  The code indicates what went
   wrong, the LCS, or message is human-readable text that may provide additional
   information on what occurred.

   The "errorCode" attribute is for an expired context SHALL result in enumerated type and has one of the LCS not
   returning a <contextResponse> in
   following values:

   o  _badMessage_: The LIS was unable to understand the subsequent heldResponse.

4. content of the
      message.

   o  _unknownContext_: The LIS was unable to find the context.

   o  _failed_: The LIS was unable to perform the requested operation.

   A Target implementing this specification MUST accept a HELD error
   message as a valid response to a create context or update context
   message.

   <hc:contextError
             xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
             code="failed"
             message="unable to update context">
   </hc:contextError>

                Figure 5: contextError With Message Example

5.5.  Location URI and id Context Identifier Generation Rules

   A primary aim of this specification is to provide an End-Point with
   the ability a Target a means to void
   cancel a location URI when so that it is associated with a
   context. can no longer be used to provide its
   location.  To achieve this, a location URI generated as part of a
   context creation needs to be unique with in the scope of the LCS, LIS, and
   applicable
   identify only to that context.  If the End-Point Target destroys a context and then
   subsequently creates a new one, URIs associated the new context MUST
   be different from those generated for the previous context.
   [I-D.ietf-geopriv-http-location-delivery] and
   [I-D.ietf-geopriv-lbyr-requirements] provide guideance on the
   creation and desired characteristcs of a location URI.

   The context id identifier provided by the LCS LIS to the End-Point Target in the
   <contextResponse>
   context response message MUST be unique per context, and SHOULD MUST be different from
   the identifier provided in any generated location URI.  This latter constraint
   ensures that possession of a location URI does not automatically
   provide access and control over the internals of the context.

   A context id identifier is generated by an LCS a LIS to uniquely identify a
   context.
   The context id MUST NOT include any information that could be used to
   identify the Target or End-Point.  Similarly, it  It MUST NOT be feasible for a third-party to easily
   determine a context id identifier by knowing the identity of the Target or End-Point. Target.
   This implies that internal correlation (using a hash-table or
   similar) is the only method that the LCS LIS can use to associate a
   context id with a particular End-
   Point.

5. Target.

6.  XML Schema

 <?xml version="1.0"?>
 <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:heldCx="urn:ietf:params:xml:ns:geopriv:held:context"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     elementFormDefault="qualified" attributeFormDefault="unqualified">

   <xs:simpleType name="locationType">
     <xs:restriction base="xs:token">
       <xs:enumeration value="any"/>
       <xs:enumeration value="civic"/>
       <xs:enumeration value="geodetic"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="codeType">
     <xs:restriction base="xs:token">
       <xs:enumeration value="created"/>
       <xs:enumeration value="updated"/>
       <xs:enumeration value="destroyed"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="errorCodeType">
     <xs:restriction base="xs:token">
       <xs:enumeration value="badMessage"/>
       <xs:enumeration value="unknownContext"/>
       <xs:enumeration value="failed"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="useType">
     <xs:union>
       <xs:simpleType>
         <xs:restriction base="xs:token">
           <xs;enumeration value="unlimited"/>
         </xs:restriction>
       </xs:simpleType>
       <xs:positiveInteger/>
     </xs:union>
   </xs:simpleType>

   <xs:complexType name="createContextMsg">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:sequence>
           <xs:element name="lifeTime" type="xs:nonNegativeInteger "
                   minOccurs="1" maxOccurs="1"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="lifeTime" type="xs:integer"
                       use="optional"/> name="uses" type="heldCx:useType"
                       use="optional" default="unlimited"/>
         <xs:attribute name="snapshot" type="xs:boolean"
                       use="optional" default="false"/>
         <xs:attribute name="locationType" type="heldCx:locationType"
                       use="optional" default="any"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="uriSetType">
        <xs:complexContent>
           <xs:sequence>
             <xs:element name="locationURI" type="xs:anyURI"
                         maxOccurs="unbounded"/>
           </xs:sequence>
        </xs:complexContent>
    </xs:complexType>

   <xs:complexType name="contextResponseMsg">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:sequence>
           <xs:element name="locationUriSet" type="heldCx:uriSetType"
                   minOccurs="1" maxOccurs="1"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="id" type="xs:token"
                       use="required"/>
         <xs:attribute name="expires" type="xs:dateTime"
                       use="required"/>
         <xs:attribute name="uses" type="xs:positiveInteger"
                       use="optional"/>
         <xs:attribute name="snapshot" type="xs:boolean"
                       use="optional"/>
         <xs:attribute name="locationType" type="heldCx:locationType"
                       use="optional"/>
         <xs:attribute name="code" type="heldCx:codeType"
                       use="required"/>

         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

  <xs:complexType name="updateContextMsg">
     <xs:complexContent>
       <xs:restriction base="xs:anyType"> base="heldCx:">
         <xs:sequence>
           <xs:element name="lifeTime" type="xs:nonNegativeInteger "
                   minOccurs="0" maxOccurs="1"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="id" type="xs:token"
                       use="required"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

 <xs:complexType name="contextErrorMsg">
     <xs:complexContent>
       <xs:restriction base="xs:anyType">
         <xs:sequence/>
         <xs:attribute name="lifeTime" type="xs:integer" name="errorCode" type="heldCx:errorCodeType"
                       use="required"/>
         <xs:attribute name="message" type="xs:token"
                       use="optional"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

   <xs:element name="createContext" type="heldCx:createContextMsg"/>
   <xs:element name="updateContext" type="heldCx:updateContextMsg"/>
   <xs:element name="contextResponse" type="heldCx:contextResponseMsg"/>
   <xs:element name="contextError" type="heldCx:contextErrorMsg"/>

 </xs:schema>

                    Figure 5: LCS response to updateContext

6.  Guidelines For Defining 6: Context Data Extensions

   A context contains specific information about an End-Point and is
   stored on the LCS.  It is impossible to predetermine all information
   that an End-Point may want or need stored in a context so the context
   control mechanisms need to be flexible to allow easy extensibility.
   When defining context data extensions it is necessary to consider how
   they will be used; this includes not only how to provide the
   information from the End-Point to the LCS, but also acceptance and
   error indications from the LCS back to the End-Point.  For example a
   context may be created with several extensions included, how does the
   LCS indicate that extensions 1 and 3 were successful but that
   extension 2 had a problem in its formatting?  Guidelines for
   designing context extensions that provide functionality are described
   in this section.

   Two basic types of context data extension are envisioned.  The first
   consist of data provided by the End-Point to be consumed by the LCS;
   for example information pertaining to PIDF-LO construction, usage-
   rules, and authorization policies.  The second type of data consists
   of a two way exchange between the End-Device and the LCS; for example
   exchanging location determination capabilities.

   When defining a context data extension it is necessary to ensure that
   the LCS can provide an adequate response to the End-Point application
   indicating acceptance or rejection of the data provided.  This may be
   an explicit OK or FAIL message within the extension namespace, or it
   may be an attribute associated with part of a larger data exchange.
   Either way it is mandatory for a context data extension to provide
   this functionality.

   When defining information to be included in a context data extension
   consideration should be given to how that data can be removed from
   the context.  In some cases it may be necessary to void the context
   on the LCS in order to remove information, but this SHOULD be treated
   as a last resort and not used as the primary mechanism for removing
   data from the context. Management Schema

7.  Security Considerations

   There are several security concerns associated with the details in
   this specification.  The first is to do with the nature of the
   sensitivity of any data passed from the End-Point Target to the LCS LIS for
   inclusion in a context.  The second is the ability of the LCS LIS to
   contain the number of contexts that it will permit to exist for a
   given End-Point Target address.  Finally, there is a threat of Targets
   performing DoS attacks on the LIS by trying to create large numbers
   of short-lived contexts that result in the LIS expending resources in
   message processing.

   HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of
   TLS for exchanges between an End-Point a Target and the LCS. LIS.  This is deemed
   sufficiently secure
   adequate to provide confidentiality to hide any contextual data from a would-be
   eavesdropper while the data is in
   transit.  The LCS LIS implementation and the operator of the LCS LIS need to
   take sufficient steps to ensure that active contextual data on the LCS
   LIS is not readily available to anyone other than the End-Point that owns the data. Target.  The End-Point
   Target MUST not NOT provide any information to the LCS LIS that it does not
   want the
   LCS LIS to know or be able to use in some capacity associated
   with determination or providing of the End-Point's Target's location.  The LCS
   SHALL not use any context information provided to it by an End-Point
   except to assist it with the determination and generation of location
   information associated with the End-Point.

   It is quite conceivable that an LCS a LIS will be required to provide
   location to end hosts Targets residing behind a NAT; a DSL home router with 5
   PCs attached is a good example this situation.  In this case it is
   reasonable for each device to create its own context on the LCS, LIS, and
   for the LCS LIS to treat each context individually even though the LCS LIS
   cannot make any other distinction between the end hosts; that is,
   they share a common IP address/identity from the LCS LIS perspective.  It
   may even

   Given the constraints that can be reasonable in some situations for a single device added to a context and the way that
   a Target might want
   more than one context. to manage expiry separately, a Target may use
   multiple contexts as a way to isolate applications from each other.
   For instance, a Target can create a context for each application so
   that it can revoke access to its location information for each
   without affecting other applications' access.  This environment however environment,
   however, opens the LCS LIS to a type of denial of service attack through
   an overload on of contexts.  It is RECOMMENDED that an implementor implementer of
   this specification include mechanisms to restrict to the maximum
   number of contexts that can be created on the LCS LIS by an individual End-Point.  It is RECOMMENDED
   that an LCS operator impose limits
   Target.

   Using short-term location URIs in a carefully controlled manner may
   obviate the need for individual location authorization policies on context creation such that it
   is restricted
   the LIS.  This leads to a sustainable level. reduced LIS complexity and the amount of
   private information that the Target need share with the LIS.  This
   specification provides the ability to for an End-Point a Target to void cancel a location
   URI which extends the End-Point's Target's ability to enforce it
   rights its entitlement to
   privacy.  Using the mechanisms described in this memo an
   End-Point a target can
   create URIs with short validity periods, periods; this restricts how long a
   third-party is able to obtain the location of the End-
   Point Target while still
   allowing the End-Point Target the convenience of using a location reference.  Using short-term location URIs in a carefully
   controlled manner may obviate the need for individual location
   authorization policies on the LCS.  This leads to reduced LCS
   complexity and the amount of private information that the End-Point
   need share with the LCS.

   The generation of context identifiers by the LCS LIS is a critical
   component to supporting the functionality described in this memo.
   The LCS LIS MUST follow the rules described in Section 4 5.5 for generating
   context identifiers.

8.  IANA Considerations

   This document registers the schema and associated namespace with
   IANA.

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

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

      URI: urn:ietf:params:xml:ns:geopriv:held:context

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), James Winterbottom
      (james.winterbottom@andrew.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 Context Management Messages</title>
             </head>
             <body>
               <h1>Namespace for HELD Context Management Messages</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:held:context</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

8.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:geopriv:held:context
   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      James Winterbottom (james.winterbottom@andrew.com).

   Schema:  The XML for this schema can be found as the entirety of
      Figure 5 6 of this document.

9.  Acknowledgements

   Thanks to Adam Muhlbauer and Neil Justusson for their comments on the
   pre-version of this draft.

Appendix A.  Context Extensions

   A context contains specific information about a Target and is stored
   on the LIS.  As with other protocols it is necessary to consider
   extensibility.  When defining context data extensions it is necessary
   to consider how they will be used; this includes not only how to
   provide the information from the Target to the LIS, but also
   acceptance and error indications from the LIS back to the Target.
   For example, a context may be created with several extensions
   included, how does the LIS indicate that extensions 1 and 3 were
   successful but that extension 2 had a problem in its formatting?
   Guidelines for designing context extensions that provide
   functionality are described below.

   Two basic types of context data extension are envisioned.  The first
   consist of data provided by the Target to be consumed by the LIS; for
   example information pertaining to PIDF-LO construction, usage-rules,
   and authorization policies.  The second type of data consists of a
   two way exchange between the Target and the LIS; for example
   exchanging location determination capabilities.  Extensibility to the
   context scheme is to allow additional elements to be added to the
   context easily.  The general idea is shown in Figure 8.

     <hc:createContext
             xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context">
       <lifeTime>7200</lifeTime>
       <ex1:extension-1
             xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1">
         <ex1:value>7200</ex1:value>
       </ex1:extension-1>
       <extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>
       <extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>
       .
       .
       .
       <extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>
   </hc:createContext>

                 Figure 8: Create Context with Extensions

   When defining a context data extension it is necessary to ensure that
   the LIS can provide an adequate response to the Target indicating
   acceptance or rejection of the data provided.  This may be an
   explicit OK or FAIL message within the extension namespace, it may be
   an attribute associated with part of a larger data exchange, or it
   may result in the LIS failing to create the context at all.
   Regardless, it is mandatory for a context data extension to provide
   an indication of success or failure.

  <hc:contextResponse
          xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
          code="created"
          id="uhvuhdbnuiehudbnvcujevuijeijcvij"
          uses="unlimited"
          snapshot="false"
          locType="any"
          expires="2007-08-01T13:00:00">
    <locationUriSet>
      <locationURI>
         https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
      </locationURI>
      <locationURI>
         sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
      </locationURI>
    </locationUriSet>
    <ex1:extension-1 xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1"
                  ex1:response="OK"/>
    <ex2:extension-2 xmlns:ex2="urn:ietf:params:xml:ns:geopriv:held:ex2"
                  ex2:response="OK"/>

    <ex3:extension-3
         xmlns:ex3="urn:ietf:params:xml:ns:geopriv:held:ex3">
      <datum-3>data</datum-3>
      <stuff>guff in here for extension</stuff>
    </ex3:extension-3>
</hc:contextRresponse>

                  Figure 9: LIS response to createContext

   When defining information to be included in a context data extension
   consideration should be given to how that data can be removed from
   the context.  In some cases it may be necessary to void the context
   on the LIS in order to remove information, but this SHOULD be treated
   as a last resort and not used as the primary mechanism for removing
   data from the context.

Appendix B.  HELD Compliance to IETF Location Configuration Protocol
             Location Reference Requirements

   This section describes how HELD and this specification comply to the
   LCP location reference requirements stipulated in
   [I-D.ietf-geopriv-lbyr-requirements].

   High-level requirements for a location configuration protocol.

   C1.  "Location URI support - LCP: The configuration protocol MUST
        support a location reference in URI form."

        COMPLY.  HELD only provides location references in URI form.

   C2.  "Location URI expiration: The LCP MUST support the ability to
        specify to the server, the length of time that a location URI
        will be valid."

        COMPLY.  HELD with the context management extensions described
        in this document provide the Target the ability to specify
        expiry times for location URIs.

   C3.  "Location URI cancellation: The LCP MUST support the ability to
        request a cancellation of a specific location URI."

        COMPLY.  HELD with the context management extensions described
        in this document provide the Target the ability to void location
        URIs when required.

   C4.  "Random Generated: The location URI MUST be hard to guess, i.e.,
        it MUST contain a cryptographically random component."

        COMPLY.  The HELD specification and this document provide
        specific guidance on the security surrounding location URI
        generation.

   C5.  "Identity Protection - LCP: The location URI MUST NOT contain
        any information that identifies the user, device or address of
        record within the URI form."
        COMPLY.  The HELD specification and this document provide
        specific guidance on the anonymity of the Target with regards to
        the generation of location URIs.

   C6.  "Reuse flag default: The LCP MUST support the default condition
        of a requested location URI being repeatedly reused."

        COMPLY.  HELD with the context management extensions described
        in this document provide the Target the ability to specify how
        many times a location URI may yield the location of Target.

   C7.  "One-time-use: The LCP MUST support the ability for the client
        to request a 'one-time-use' location URI (e.g., via a reuse flag
        setting)."

        COMPLY.  HELD with the context management extensions described
        in this document provide the Target the ability to specify how
        many times a location URI may yield the location of Target.
        This value may be set to 1 to create a one-time URI.

10.  Normative References

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

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

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

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-00
              draft-ietf-geopriv-http-location-delivery-02 (work in
              progress), June September 2007.

   [I-D.ietf-geopriv-l7-lcp-ps]
              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.

Author's Address

   [I-D.ietf-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work
              in progress), September 2007.

Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Phone: +61 242 212938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/products/geometrix

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Phone: +49 89 636 40390
   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com

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

   Phone: +61 242 212915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/products/geometrix

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).