Geopriv J. Winterbottom
Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig
Expires: April 8, 2008 Nokia Siemens Networks
M. Thomson
Andrew Corporation
October 6, 2007
HELD Protocol Context Management Extensions
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 April 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom, et al. Expires April 8, 2008 [Page 1]
Internet-Draft HELD Context October 2007
Abstract
This document describes a protocol extension for the HTTP Enabled
Location Delivery (HELD) protocol. It allows a Target to manage
their location information on 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. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5
4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6
4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Location Type URIs . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8
5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9
5.3. Context Response Message . . . . . . . . . . . . . . . . . 10
5.4. Context Error Messages . . . . . . . . . . . . . . . . . . 12
5.5. Location URI and Context Identifier Generation Rules . . . 12
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 19
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22
Appendix B. HELD Compliance to IETF Location Configuration
Protocol Location Reference Requirements . . . . . . 24
10. Normative References . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Winterbottom, et al. Expires April 8, 2008 [Page 2]
Internet-Draft HELD Context October 2007
1. Introduction
The HTTP Enabled Location Delivery (HELD) protocol specification
[I-D.ietf-geopriv-http-location-delivery] provides a set of features
that can be used by a Target to retrieve location information from a
Location Information Server (LIS). The basic HELD specification does
this in a more or less stateless manner, and when a location URI is
retrieved the Target has no way of controlling how the URI is used; a
Location Recipient in pocession of the location URI can get the
Target's location until the URI expires. This basic mechanism may be
reasonable in a limited set of applications, but is unacceptable in a
broader range of applications. This position is highlighted in
[I-D.ietf-geopriv-lbyr-requirements] which describes requirements for
constraints relating to location URIs. This specification provides
support for these requirements in HELD.
Winterbottom, et al. Expires April 8, 2008 [Page 3]
Internet-Draft HELD Context October 2007
2. 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 [RFC2119].
This document reuses the terms Target, as defined in [RFC3693].
This document uses the term Location Information Server (LIS) as the
node in the access network that provides location information about a
Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].
Winterbottom, et al. Expires April 8, 2008 [Page 4]
Internet-Draft HELD Context October 2007
3. What is a Context?
A Location URI points to a LIS that is able to provide the location
of a specific Target. The LIS is able to map the URI to 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 with the request for a location URI in the
locationRequest message. The Target has no control of the 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 determined
by the LIS when the Target requests a location URI. By allowing the
Target to specify and change the life time of a context the Target is
able to create URIs for limited periods, or to terminate URIs for
which it longer wishes its location to be returned. This
specification provides explicit support for this functionality.
Winterbottom, et al. Expires April 8, 2008 [Page 5]
Internet-Draft HELD Context October 2007
4. Constraints
Constraints restrict the ability of a Location Recipient to resolve a
location URI to location information. The constraints are selected
by the Target and they are provided to the LIS that maintains them
along with the context. A LIS, understanding this specification,
receives constraints provided by the Target, and returns a set of
URIs influenced by the constraints.
A single Target may want to place different contraints on different
references and hence may have multiple contexts on the LIS. The
constraints describe what actions the LIS MUST take when a URI
associated with the context 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 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 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 supports both
SIP and HTTP URIs it is the combination of URI accesses and NOTIFY
messages that constitutes the usage value, each time the Target's
location is provided constitutes a usage.
Winterbottom, et al. Expires April 8, 2008 [Page 6]
Internet-Draft HELD Context October 2007
4.2. Snapshot URIs
A snapshot URI points to the location of the Target at a specific
point in time, and no matter how many times the URI is accessed it
will always yield the same location. This is useful if, for example,
the Target does not want to be tracked. In this specification the
location snapshot to which a snapshot URIs points is captured when
the context 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.
Winterbottom, et al. Expires April 8, 2008 [Page 7]
Internet-Draft HELD Context October 2007
5. Protocol Details
This specification introduces four new HELD messages, create context
(<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 sent using the
application/held+xml MIME type as defined in
[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 constraints
described in Section 4 and consist of three attributes and one
element described below:
o "uses": an optional attribute instructing the LIS on how many
times a URI may yield the location of the Target. This is a
positive integer, and has a default value of _unlimited_. The LIS
SHOULD support the Target specifying up to at least 100 uses.
o "snapshot": an optional attribute instructing the LIS to take a
snapshot of the Target's location for use with the context. This
a 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 optional attribute instructing the LIS on the
form of location that URI MUST provide. This is an enumeration
and may have a value of _geodetic_, _civic_, or _any_. If
unspecified by the Target the LIS will use a value of _any_. If
the Target specifies a location type that the 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 LIS should keep the context for. The LIS MAY
create the context with a shorter life time than was requested,
but the life time MUST NOT be longer than was requested.
Winterbottom, et al. Expires April 8, 2008 [Page 8]
Internet-Draft HELD Context October 2007
<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 location of the 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 identify the context to be updated. It does this by
including a context identifier that is provided to it by the LIS when
the context is 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 an update context
message, the LIS needs to calculate a new context expiry time. The
LIS MUST do this by adding the new life time value to the current
time on the LIS. This mechanism means the Target can terminate a
context at any time. It does this by updating the context with a
life time of 0, which results in the LIS setting the context expiry
Winterbottom, et al. Expires April 8, 2008 [Page 9]
Internet-Draft HELD Context October 2007
time to the present. The LIS MAY also terminate a context if the
life time value is set to 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 Target about the outcome of context operations
through the context response message. The LIS MUST always send a
context response message to a Target in response to a create context
or update context message when the outcome was successful. The
context response message contains a "code" attribute indicating the
performed operation, and the other attributes and elements indicating
the state of the context.
The "code" attribute is an enumerated type and has one of the
following values:
o _created_: The context was successfully created.
o _destroyed_: The context was destroyed.
o _updated_: The context was successfully updated.
The following list details the other attributes are may be returned
in a context response message.
id: The identifier allocated to 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 in all update requests. The
LIS MUST return and "id" in all context response messages.
uses: The number of times that the context will yield the Target's
location. The LIS MAY report either the original value, or the
number of remaining uses. 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.
Winterbottom, et al. Expires April 8, 2008 [Page 10]
Internet-Draft HELD Context October 2007
snapshot: The value of the 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. The LIS MUST report this
value for all responses pertaining to a known and valid context.
This value MAY be omitted when indicating that a context has been
destroyed.
expiry: The time at which the 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 context repsonse message.
In addition to the above attributes, the LIS also provides a set of
URIs that can used to access the Target's location with the surety
that the context constraints will be applied. A URI set is returned
whenever a context is successfully created on the LIS, and this set
remains unchanged for the lifetime of the context. A context
response message sent in reply to the 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
Winterbottom, et al. Expires April 8, 2008 [Page 11]
Internet-Draft HELD Context October 2007
5.4. Context Error Messages
When the LIS unable to perform the requested context operation it
need to inform the Target of this. It does this using a context
error message. The context error message consists of a "errorCode"
and an optional "message" attribute. The code indicates what went
wrong, the message is human-readable text that may provide additional
information on what occurred.
The "errorCode" attribute is an enumerated type and has one of the
following values:
o _badMessage_: The LIS was unable to understand the 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 Context Identifier Generation Rules
A primary aim of this specification is to provide a Target a means to
cancel a location URI so that it 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 LIS, and
identify only that context. If the Target destroys a context and
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 identifier provided by the LIS to the Target in the
context response message MUST be unique and MUST be different from
the identifier provided in any location URI. This latter constraint
Winterbottom, et al. Expires April 8, 2008 [Page 12]
Internet-Draft HELD Context October 2007
ensures that possession of a location URI does not automatically
provide access and control over the internals of the context.
A context identifier is generated by a LIS to uniquely identify a
context. It MUST NOT be feasible for a third-party to easily
determine a context identifier by knowing the identity of the Target.
This implies that internal correlation (using a hash-table or
similar) is the only method that the LIS can use to associate a
context id with a particular Target.
Winterbottom, et al. Expires April 8, 2008 [Page 13]
Internet-Draft HELD Context October 2007
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>
Winterbottom, et al. Expires April 8, 2008 [Page 14]
Internet-Draft HELD Context October 2007
<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="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"/>
Winterbottom, et al. Expires April 8, 2008 [Page 15]
Internet-Draft HELD Context October 2007
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="updateContextMsg">
<xs:complexContent>
<xs:restriction 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="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 6: Context Management Schema
Winterbottom, et al. Expires April 8, 2008 [Page 16]
Internet-Draft HELD Context October 2007
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 Target to the LIS for
inclusion in a context. The second is the ability of the LIS to
contain the number of contexts that it will permit to exist for a
given 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 a Target and the LIS. This is deemed
adequate to provide confidentiality to any contextual data in
transit. The LIS implementation and the operator of the LIS need to
take sufficient steps to ensure that active contextual data on the
LIS is not readily available to anyone other than the Target. The
Target MUST NOT provide any information to the LIS that it does not
want the LIS to know or be able to use in some capacity associated
with determination or providing of the Target's location.
It is quite conceivable that a LIS will be required to provide
location to 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 LIS, and
for the LIS to treat each context individually even though the LIS
cannot make any other distinction between the end hosts; that is,
they share a common IP address/identity from the LIS perspective.
Given the constraints that can be added to a context and the way that
a Target might want 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, opens the LIS to a type of denial of service attack through
an overload of contexts. It is RECOMMENDED that an implementer of
this specification include mechanisms to restrict to the maximum
number of contexts that can be created on the LIS by an individual
Target.
Using short-term location URIs in a carefully controlled manner may
obviate the need for individual location authorization policies on
the LIS. This leads to reduced LIS complexity and the amount of
private information that the Target need share with the LIS. This
specification provides the ability for a Target to cancel a location
URI which extends the Target's ability to enforce its entitlement to
Winterbottom, et al. Expires April 8, 2008 [Page 17]
Internet-Draft HELD Context October 2007
privacy. Using the mechanisms described in this memo a target can
create URIs with short validity periods; this restricts how long a
third-party is able to obtain the location of the Target while still
allowing the Target the convenience of using a location reference.
The generation of context identifiers by the LIS is a critical
component to supporting the functionality described in this memo.
The LIS MUST follow the rules described in Section 5.5 for generating
context identifiers.
Winterbottom, et al. Expires April 8, 2008 [Page 18]
Internet-Draft HELD Context October 2007
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
Winterbottom, et al. Expires April 8, 2008 [Page 19]
Internet-Draft HELD Context October 2007
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 6 of this document.
Winterbottom, et al. Expires April 8, 2008 [Page 20]
Internet-Draft HELD Context October 2007
9. Acknowledgements
Thanks to Adam Muhlbauer and Neil Justusson for their comments on the
pre-version of this draft.
Winterbottom, et al. Expires April 8, 2008 [Page 21]
Internet-Draft HELD Context October 2007
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
Winterbottom, et al. Expires April 8, 2008 [Page 22]
Internet-Draft HELD Context October 2007
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.
Winterbottom, et al. Expires April 8, 2008 [Page 23]
Internet-Draft HELD Context October 2007
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."
Winterbottom, et al. Expires April 8, 2008 [Page 24]
Internet-Draft HELD Context October 2007
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.
Winterbottom, et al. Expires April 8, 2008 [Page 25]
Internet-Draft HELD Context October 2007
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-02 (work in
progress), 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-05 (work in
progress), September 2007.
[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.
Winterbottom, et al. Expires April 8, 2008 [Page 26]
Internet-Draft HELD Context October 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
Winterbottom, et al. Expires April 8, 2008 [Page 27]
Internet-Draft HELD Context October 2007
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).
Winterbottom, et al. Expires April 8, 2008 [Page 28]