wdiff draft-winterbottom-geopriv-held-context-03.txt draft-winterbottom-geopriv-held-context-04.txt

Geopriv J. Winterbottom
Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig
Expires: April 2, October 16, 2009 Nokia Siemens Networks
M. Thomson
Andrew Corporation
September 29, 2008

HELD Protocol Context Management Extensions
draft-winterbottom-geopriv-held-context-03.txt
April 14, 2009

Establishing Location URI Contexts using HTTP-Enabled Location Delivery
(HELD)
draft-winterbottom-geopriv-held-context-04

Status of this This Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she

This Internet-Draft is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
provisions of BCP 78 and 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 2, October 16, 2009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

This document describes a protocol extension for the HTTP Enabled 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
3. What is a Context? HELD Contexts . . . . . . . . . . . . . . . . . . . . . . 5
4. Constraints . . 4
3.1. Simplified Model . . . . . . . . . . . . . . . . . . . . . 4
3.2. Authorization Policies . . 6
4.1. Limited Use URIs . . . . . . . . . . . . . . . . 5
3.3. Context Lifetime . . . . . . 6
4.2. Snapshot URIs . . . . . . . . . . . . . . . 6
3.4. Snapshot Contexts . . . . . . . 7
5. . . . . . . . . . . . . . 6
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. 6
4.1. Create Context Message . . . . . . . . . . . . . . . . . . 8
5.2. . . . . 7
4.2. Update Context Message . . . . . . . . . . . . . . . . . . 9
5.3. . . . . 8
4.3. Context Response Message . . . . . . . . . . . . . . . . . 10
5.4.
4.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11
5.5.
4.5. Location URI and Context Identifier Generation Rules . . . 12
6.
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Multiple Contexts from the 'Same' Target . . . . . . . . . 16
8.
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. 16
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 18
8.2. 17
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 18
8.3. New 17
7.3. HELD Error Code Registration . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . 20
Appendix A. Context Extensions . . . . . . . . . . . . . 18
9. References . . . . 21
Appendix B. HELD Compliance to IETF Location Configuration
Protocol Location Reference Requirements . . . . . . 23
10. Normative References . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 19
Appendix A. Compliance to Location by Reference Requirements . . 27 20

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 LIS is able to optionally
provide a more or less stateless manner, and when location URI [I-D.ietf-geopriv-lbyr-requirements], which
provides a reference to location information.

A location URI that is
retrieved provided by a LIS using the Target has basic HELD
specification, is essentially immutable once retrieved. There is no way
means provided of controlling how the URI is used; used. A default policy
is applied to the URI, which is fixed until the location URI expires;
a Location Recipient in pocession possession of the location URI can get retrieve
the Target's location until the URI expires. expiry time lapses.

This basic mechanism may be reasonable in a limited set of
applications, but is unacceptable in a broader range of applications. This position
In particular, the ability to change policy dynamically is highlighted in required
to better protect the privacy of the Target.
[I-D.ietf-geopriv-lbyr-requirements] which describes enumerates several requirements for
constraints
relating to location URIs. URIs that cannot be achieved using the basic
HELD specification. This specification provides support for these
requirements in HELD.

Two new forms of HELD request are defined by this document. These
requests relate to the creation and maintenance of a _HELD context_,
a concept that is explained in more detail in Section 3.

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 uses the terms Target, as defined in [RFC3693].

This document uses the term [RFC3693] (Target, Location
Recipient, Location Server), [I-D.ietf-geopriv-lbyr-requirements]
(location URI), and [I-D.ietf-geopriv-l7-lcp-ps] (Location
Information Server, or LIS).

The distinction between Location Server (LS) and Location Information
Server (LIS) as the
node in is important. LS is used to refer to the access network role that provides
serves a location information about URI, whereas a
Target. This term LIS is also used in [I-D.ietf-geopriv-l7-lcp-ps]. the role that provides the
location configuration. Both roles might be assumed by the same
entity, but the roles could be separate.

3. What is a Context? HELD Contexts

A Location location URI points to a LIS that is able a reference to provide the current location of a specific Target.
The LIS is able to map host identified in the URI URI, the Location Server (LS), serves
requests to a location URI using two classes of data:

authorization policy: Authorization policies are set by Rule Makers
and determine whether the requester is permitted to receive
location information and whether there are any constraints on that
information.

location determination inputs: Information on the identity of the
Target inside its administrative domain. We call this mapping
a "context". In the basic HELD specification and how location information for that Target can be
acquired might be saved by the context LS.

This information is
implicitly created associated with the request for a every location URI in the
locationRequest message. served by an
LS. The Target has no control collection of data used by the mapping
from the URI to the Target's location. This specification provides LS establishes a
degree of control to the Target, allowing it to specify rules to "context"
for the
LIS on how a context should map a URI to location information.

A context expires when it reaches dereference request made by a certain age, at which time the
mapping between the URI and the Target's location ceases. Location Recipient.

In the
basic HELD specification [I-D.ietf-geopriv-http-location-delivery], the exiry time establishment
of the context necessary contextual information is determined
by implicit. Creation of a
location URI implies that the LIS when has provided the Target LS with sufficient
information to service requests a location to that URI. By allowing

This document provides a more explicit mechanism for the
Target to specify creation and change the life time
management of a context the Target is
able to create URIs for limited periods, or to terminate URIs for
which it no longer wishes its contextual information used in serving a location to be returned.
URI. This
specification provides explicit support for information - dubbed a "HELD context" (simply "context" in
this functionality.

4. Constraints

Constraints restrict document) - can be created, updated and destroyed at the ability request
of the Device. In addition, a Location Recipient Device is able to resolve establish
authorization policies in the form of common policy documents
[RFC4745] that provide greater control over how a location URI to location information. The constraints are selected is
served by the Target and they are provided to the LIS that maintains them
along with the context. A LIS, understanding LS.

3.1. Simplified Model

The model assumed in this specification,
receives constraints provided by the Target, and returns shown in Figure 1, is a set
simplified variant of
URIs influenced by that in [RFC3693] that includes the constraints.

A single LIS entity.

+------------+
| |
| Rule Maker | +-------------+ +-----------+
| | | | | |
+ - - -- - - + | Location | | Location |
| | | Server |-----------| Recipient |
| Target | | | (LDP) | |
| | + - - - - - - + +-----------+
+ - - -- - - + | | |
| | | Location | |
| Device |-----------| Information | |
| | (LCP) | Server | |
+------------+ | | |
| +-------------+ |
| |
`------------------(Conveyance)-------------------'

Figure 1: HELD Contexts Model

This model assumes some form of relationship between a Rule Maker,
Target may want to place different contraints on different
references and hence may have multiple contexts on Device; for instance, the LIS. Rule Maker and Target might be
the same person. The
constraints describe what actions Device is operated under the LIS MUST take when control of a URI
associated Rule
Maker and is able to provide authorization policies or disseminate
location URIs in accordance with the context is accessed. Rule Maker's wishes.

This document describes two
basic constraints that also assumes a Target can use in combination for relationship is assumed between LIS and
LS. LIS and LS together generate location URIs and maintain context
information. These roles could be filled by the same
context. Once set, these entity.

The location configuration protocol (LCP) interface is extended by
this document to include a rules remain in force of interface for the life of Rule Maker
associated with the
context.

4.1. Limited Use URIs

A limited Target and Device. This model does not preclude
the existence of other Rule Makers that use URI can only be accessed other rules interfaces.

3.2. Authorization Policies

A Device is able to specify an authorization policy when creating or
updating a fixed number of times context. The authorization policy states which Location
Recipients are able to
yield the access location of information through the Target. Each time
context and the URI associated URIs, plus any other constraints on this
access.

A Device is used able to provide a policy document in the location form of a common
policy document [RFC4745] or an "https:" reference to one. Existence
of an explicit authorization policy implies that the Target one usage "authorization
by access control lists" model ([I-D.ietf-geopriv-lbyr-requirements])
is consumed. Once to be applied. The LS uses the
limit authorization policy document to
control how location information is reached provided to Location Recipients.

Absence of policy, or an explicit indication otherwise, indicates
that the URI no longer yields LS is permitted to apply the location "authorization by possession"
model ([I-D.ietf-geopriv-lbyr-requirements]). Any Location Recipient
that proves possession of the Target
and the location URI is deemed spent.

By setting the usage limit by making a location
dereference request to 1, the Target URI is able to create a one-
time-URI permitting a Location Recipient granted permission to obtain receive the Target's
location only once. Setting information. Location URIs for the usage limit associated context have
random components with enough entropy to something higher than
1 creates functionality analogous make possession more likely
to be as a metro-ticket, where a Location
Recipient in possession result of receiving the location URI can access from the Target's location
many more times, but not exceeding Device than
guesswork.

3.3. Context Lifetime

A HELD context has a finite lifetime. This limits the imposed limit.

Not setting time that a usage limit provides similar semantics
context might refer to a Device that has since left the URI in network. Of
course, a LIS might have a means of detecting the base HELD specification, enabling absence of a Location Recipient to
continually obtain given
Device, invaliding any contexts when the Target's location until Device is no longer present.

The lifetime of the URI expires due to
age.

When context is negotiated between Device and LIS.
The Device requests a HELD certain lifetime and the LIS provides a
location URI that is assigned valid for up to a context, the limit requested time. A Device is
able to extend the number lifetime of
times that a context by updating the URI context
information. Given regular updates, a context might persist
indefinitely, providing that authorization by possession is not used.

A Device can be accessed before request that the LIS returns an error.
In remove context information,
invalidating the case of SIP or pres URIs it is associated location URIs, by the number of NOTIFY messages
that are sent prior same mechanism used
to extend the LIS returning an error. Where lifetime.

3.4. Snapshot Contexts

At the time that a context
supports SIP, pres, and HELD URIs it is created, the combination of URI
accesses and NOTIFY messages Device is able to request
that constitutes the usage value, each
time the Target's location is provided constitutes a usage.

4.2. Snapshot URIs

A snapshot URI points context refer to a static document that is created at the location
time of the Target at request. The LIS creates a specific
point in time, Location Object (LO) based on the
associated HELD request parameters and no matter how many times stores the LO. All requests
to the location URI is accessed it
will always yield created in response to this request are served
based on the same location. stored LO.

This is useful if, basic constraint on the context applies for example, the Target does not want to be tracked. In this specification life of the
location snapshot
context. Only the application of authorization policy rules can
change what is provided to which a snapshot URIs points different Location Recipients. If
authorization by possession is captured when used, the context associated location URI is created on the LIS.

5.
different to a Location Object only in that it needs to be
dereferenced.

4. Protocol Details

This specification introduces three new HELD messages, create context
(<createContext>), update context (<updateContext>), and context
response (<contextResponse>).

All context-related messages are HELD messages, sent using the
"application/held+xml" MIME type defined in
[I-D.ietf-geopriv-http-location-delivery].

A LIS that does not understand this specification is expected to return returns a HELD _unsupportedMessage_
"unsupportedMessage" error code in a HELD error "error" message. A LIS
that does understand this specification returns errors associated
with context operations in a HELD error message. New error codes
relating to failed context operations are defined in this specification. Section 4.4.

The specification assumes that the LIS was discovered as part of the
general HELD
LIS discovery process. All messages are sent using [I-D.ietf-geopriv-lis-discovery] and that the
application/held+xml MIME type as defined in
[I-D.ietf-geopriv-http-location-delivery].

5.1. LIS is
able to provide location information.

4.1. Create Context Message

The Target Device creates a context on the LIS using a create context
message. The basic A sample create context message supports the constraints
described request is shown in Section 4 and consist Figure 2.

<createContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<lifetime>7200</lifetime>
<snapshot>false</snapshot>
<policy>
<ruleset-reference>
http://policy.example.com/geolocation-policy/users/alice/index
</ruleset-reference>
</policy>
</createContext>

Figure 2: Create Context Example

The following parameters of two attributes and one element
described below:

o "uses": an optional attribute instructing the LIS on how many
times a URI may yield the location create context request are defined:

lifetime: The maximum lifetime of the Target. This is a
positive integer, and has a default value of _unlimited_. context in seconds. All
create contexts requests include this parameter. The LIS
SHOULD support the Target specifying up to at least 100 uses.

o "snapshot": an optional attribute instructing MAY
create the LIS to take context with a
snapshot of shorter lifetime than was requested, but
the Target's lifetime MUST NOT be longer than was requested.

snapshot: Whether the value provided to location for use with Recipients is fixed
from the context. time that the context is created (see Section 3.4). This
a boolean value and has parameter with a default value of _false_ "false", meaning that a
snapshot is not taken, and
the context the Target's location is determined
each at the time that the location
URI is accessed.

o "lifeTime": is dereferenced.

policy: An authorization policy, either included directly as an
instance of a mandatory element that defines common policy [RFC4745] document, or by reference as
a URI. Only one of the maximum period following forms of policy are permitted:

cp:ruleset: The Device is able to provide an authorization policy
explicitly in seconds that the LIS should keep request by including a common policy document
in the context for. The LIS MAY create the context request. A "ruleset" element is included
as a child of the "policy" element.

ruleset-reference: Alternatively, a reference to a policy
document can be included using the "ruleset-reference" element.
A Rule Maker might maintain an authorization policy on a server
(perhaps with XCAP [RFC4825]). This reference MUST be an
"https:" URI. The LS MUST retrieve the policy before granting
any Location Recipient access to location information; the
policy MAY either be retrieved immediately or as a shorter life time than was requested, Location
Recipient makes a request. The LS can be expected to retrieve
the policy document once only, but it MAY be retrieved multiple
times.

Note that the life time MUST NOT LIS could be longer than was requested.

Figure 1: createContext Example

Figure 1 shows unable to detect errors in policy
before sending a create context message defining response to a request that includes this
element. A successful context which:

o may response might be accessed 10 times

o will determine sent, even if
the location policy document cannot be retrieved by the LIS or the
referenced policy document is not understood by the LIS.

possession: Absence of policy information in a create context
request implies that authorization by possession
[I-D.ietf-geopriv-lbyr-requirements] is used for the Target each time it context.
The "possession" element provides an explicit indication that
this policy is accessed

o will to be valid applied.

otherPolicy: Alternative policy information might be provided.
This element is provided to allow for 2 hours from expansion. A LIS MAY
reject requests that contain policy that it does not understand
with the time of context creation

5.2. "badPolicy" error code.

4.2. Update Context Message

A Target can Device is able to update policy or change the life time lifetime of a context
using an update context message. As stated in Section 4 the two attributes used request. Other context parameters defined in
the
other specification might also be updated using this method.

Once created, a context creation, "uses" and that contains a "snapshot" of the Target's
location cannot be changed once made dynamic; the same applies in converse, a
dynamic context is created.

Since the Target may have cannot be made into a static snapshot.

A Device might maintain more than one context on the LIS, HELD context; therefore, the
Target
request 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 The
"context-id" is created. included in this message.

<updateContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
<lifeTime>3600</lifeTime>
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
<lifetime>3600</lifetime>
<policy>
<cp:ruleset xmlns:cp="urn:ietf:params:xml:ns:common-policy">

</cp:ruleset>
</policy>
</updateContext>

Figure 2: updateContext Life Time Change 3: Update Context Example

When a Target Device includes a life time "lifetime" element in an update context
message, the LIS needs to calculate a new lifetime of the context expiry time. The
LIS MUST do this by adding is modified. If the new life time value to requested
lifetime is longer than the current time on remaining before the LIS. This mechanism means context
expires, the Target context lifetime is lengthened. If the requested
lifetime is shorter than the remaining time, the context lifetime is
shortened.

A context that is updated continuously can terminate be maintained indefinitely
using this mechanism. The LIS MAY provide a
context at any shorter lifetime than
the requested time. It does this In particular, the total lifetime of contexts
that use authorization by updating possession MUST be limited.

This mechanism also allows for the context with cancellation of contexts. The
Device indicates a
life time context lifetime of 0, which results 0 in the LIS setting the update context expiry
time to the present.
request. The LIS MAY also terminate a context immediately if the
life time
lifetime value is set to less than 10 seconds.

<updateContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
<lifeTime>0</lifeTime>
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
<lifetime>0</lifetime>
<policy>
<possession/>
</policy>
</updateContext>

Figure 3: updateContext 4: Update Context Termination Example

5.3. Context Response Message

The LIS informs

When an update context request contains policy information, that
policy information replaces any existing policy. Omitting the Target about
"policy" element means that the previous policy remains unchanged.
If a "ruleset-reference" element is provided, the outcome LS MUST retrieve
the referenced policy document before serving subsequent requests
from Location Recipients. Conditional HTTP requests, such as those
containing the "If-Modified-Since" header MAY be used to avoid
retrieval of context operations
through the context response message. entire policy.

The rules regarding the construction of location URIs in
[I-D.ietf-geopriv-lbyr-requirements] differ based on the
authorization model used. The LIS MUST always send NOT permit a change in policy
if the location URIs associated with the context do not meet the
requirements for the updated authorization model. See Section 4.5
for more details.

4.3. Context Response Message

The context response message to a Target is sent in response to a create context
request or an update context request. This message when includes
information about 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. that has been created, updated or
destroyed.

The "code" attribute is an enumerated type and has one of the
following values:

o _created_: context response indicates what action
was accomplished by the request:

created: The context was successfully created.

o _destroyed_:

updated: The context was destroyed.

o _updated_: successfully updated.

destroyed: The context was successfully updated. destroyed.

The following list details the other attributes that may be returned
in a context response message.

id: The identifier allocated to contains a "context" element that includes
information about the context by the LIS. This
identifier is unique in that was the scope subject of the LIS. The Target MUST
keep this secret and MUST included it in all update requests. The
LIS MUST return an "id" in all context response messages.

uses: The number of times request.

id: A value that uniquely identifies the context will yield the Target's
location. The LIS MAY report either within the original value, or context
of the
number LIS. This identifier is used to identify a context for
update context requests. Knowledge of remaining uses. The LIS MUST report this value for all
responses pertaining is used by the
LIS to a known authenticate and valid context. This value MAY
be ommitted when indicating that a authorize update context has been destroyed.

snapshot: The value of the snapshot attribute in the context. requests. The
LIS
Target MUST report keep 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.

expiry: secret.

expires: 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

snapshot: Whether the context contains a known
context. snapshot of the Target's
location. This attribute MUST be provided even when value has a "code" default value of _destroyed_ is included in the context repsonse message.

In addition to the above attributes, the "false".

The LIS also provides a set of URIs that can used to access the
Target's location with the surety
that using the context constraints will be applied. A URI set is returned
whenever a context is successfully created on the LIS, and this context. The set
remains unchanged for of URIs does
not change over the lifetime of the context.

A context response message sent in reply to the create context
message in Figure 1 2 might look like Figure 4. 5.

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

Figure 4: contextResponse 5: Context Response Example

5.4.

4.4. Context Errors

When the LIS is unable to perform the requested context operation it
need to inform the Target

A set of this. It does this using a held new HELD error
message. New codes are defined minted for use in context operation errors:

o _badContextMessage_: requests
and responses:

badPolicy: The LIS (or LS) was unable to understand the content
of use the message. In general this will apply included policy due
to context messages
containing extensions it being invalid, badly formed, or inaccessible (when
"ruleset-reference" is used). A LIS MAY return an error with this
code if the policy contains no rules that could be used under any
circumstances. For instance, all the LIS does rules might have validity
intervals that do not correspond with the lifetime of the URI, or
rules might require authentication modes that are not understand.

o _unknownContext_: supported by
the LS.

unknownContext: The LIS was unable to find the context.

o _updateContextFailed_: The LIS context, possibly
because the context identifier provided was unable to updated invalid or because the requested
context.

o _createContextFailed_:
context has already expired.

contextFailure: The LIS was unable to created create or update the requested context.

A Target implementing this specification MUST accept a any

Any other HELD error message as a valid can be provided in response to a create context
or update context
message as request.

The following HELD error is sent in response to a LIS may not understand create context messages. A
request where the LIS indicates that
does understand context messages snapshot is expected to return the error
codes above under the prescribed circumstances. not supported.

Figure 5: 6: Example Error Message

5.5.

4.5. Location URI and Context Identifier Generation Rules

A primary aim of this specification is to provide a Target

Location URIs generated by a means to
cancel LIS (or LS) MUST meet the construction
requirements in [I-D.ietf-geopriv-lbyr-requirements]. In particular,
the requirements for a location URI so that it can no longer operates on the
authorization by possession model are more stringent than one that
operates on an authorization policy.

Location URIs that operate on authorization by possession MUST be used
difficult to provide its
location. To achieve this, a location URI generated as part guess. Inclusion of a
context creation needs to sequence of characters with at
least 128 bits of random entropy is RECOMMENDED. More entropy might
be unique required for location URIs with in longer lifetimes. If the scope LIS
permits changing of the LIS, and
identify only authorization model that context. If the Target destroys a context and
subsequently creates applies to a new one, URIs associated
context, then the new context more stringent requirements 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 guidance on the creation
and desired characteristcs of a location URI. complied with.

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, and it unique. Context identifiers are
secrets used to indicate authorization for context update requests.
Therefore, context identifiers MUST NOT be
feasible to determine the context-ID from the location URI. This
constraint ensures that possession easily guessable.
Inclusion of a location URI does not
automatically provide access and control over the internals sequence of the
context. It MAY be feasible to determined the characters with at least 128 bits of
random entropy is RECOMMENDED.

A location URI knowing
the context-ID however.

A context identifier is generated by a LIS to uniquely identify a
context. It MUST NOT include information that could be feasible for a third-party used in any
way to easily
determine a context identifier by knowing derive the identity value of the Target.
This implies that internal correlation (using a hash-table or
similar) is the only method context identifier. Similarly, context
identifiers MUST NOT be based on Target identity.

New contexts MUST have unique location URIs that have not previously
been used for other contexts, even if the LIS can use to associate a previous context id with a particular was for
the same Target.

5. 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:ctxt="urn:ietf:params:xml:ns:geopriv:held:context"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:simpleType name="codeType">

<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:context">
HELD Context Management
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">

This document defines messages for HELD context management.
</xs:documentation>
</xs:annotation>

<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>

<xs:complexType name="policyType">
<xs:complexContent>
<xs:restriction base="xs:token">
<xs:enumeration value="created"/>
<xs:enumeration value="updated"/>
<xs:enumeration value="destroyed"/> base="xs:anyType">
<xs:choice>
<xs:element name="ruleset-reference" type="xs:anyURI"/>
<xs:element ref="cp:ruleset"/>
<xs:element name="possession" type="ctxt:empty"/>
<xs:element name="otherPolicy" type="xs:anyType"/>
</xs:choice>
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="useType">
<xs:union memberTypes="xs:positiveInteger">
<xs:simpleType>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="createContextType">
<xs:complexContent>
<xs:restriction base="xs:token">
<xs:enumeration value="unlimited"/> base="xs:anyType">
<xs:sequence>
<xs:element name="lifeTime" type="xs:nonNegativeInteger"/>
<xs:element name="snapshot" type="xs:boolean"/>
<xs:element name="policy" type="ctxt:policyType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="createContextMsg"> name="updateContextType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="context-id" type="xs:NCName"/>
<xs:element name="lifeTime" type="xs:nonNegativeInteger "
minOccurs="1" maxOccurs="1"/> type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="policy" type="ctxt:policyType"
minOccurs="0"/>
<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:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

<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:complexType name="uriSetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="contextResponseMsg"> name="contextType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet" type="heldCx:uriSetType"
minOccurs="1" maxOccurs="1"/> type="ctxt:uriSetType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:token" type="xs:ID" 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="code" type="heldCx:codeType"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="updateContextMsg"> name="contextResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="lifeTime" type="xs:nonNegativeInteger "
minOccurs="0" maxOccurs="1"/> name="context" type="ctxt:contextType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:token" name="code" type="ctxt:codeType"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

<xs:element name="createContext" type="heldCx:createContextMsg"/> type="ctxt:createContextType"/>
<xs:element name="updateContext" type="heldCx:updateContextMsg"/> type="ctxt:updateContextType"/>
<xs:element name="contextResponse" type="heldCx:contextResponseMsg"/> type="ctxt:contextResponseType"/>

</xs:schema>

Figure 6: Context Management Schema

6. Security Considerations

There are several security concerns associated with the details in
this specification.

The first data that is to do with the nature of maintained in a HELD context is privacy sensitive
information. This information is provided by a Device for the
sensitivity
purposes of any data passed from the Target to the providing authorized Location Recipients with location
information. The LIS for
inclusion MUST NOT use the information it stores in a context.
HELD context for anything other than serving requests to the
associated location URIs.

The LS MUST enforce the authorization policy established by the
Device. The second authorization policy determines which Location
Recipients are permitted to receive location information, and how
that location information is provided. An authorization policy can
be updated by the ability of Device at any time using the update context
request; after the LIS responds to
contain this request, the number of contexts that it will permit authorization
policy applies to exist for a
given Target address. Finally, there is all subsequent requests from Location Recipients.

An authorization policy can be referenced using "ruleset-reference"
in a threat of Targets
performing DoS attacks on the create context or update context request. The LS MUST retrieve
any referenced authorization policy using HTTP over TLS [RFC2818]
before providing location information to any Location Recipient.

Context identifiers are confidential information shared only between
LIS and Device. Location URIs are also confidential if authorization
by trying to create large numbers
of short-lived contexts that result possession is chosen by the device, in which case the location URI
is shared only between LIS, Device and authorized Location
Recipients. The LIS expending resources MUST ensure that context identifiers and
location URIs are constructed following the rules described in
message processing.
Section 4.5 of this document.

HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of
TLS for exchanges between a Target Device 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 TLS provides
confidentiality, protection from modification, LIS is not readily available (and possibly
Device) authentication. Messages related to anyone other than the Target. The
Target MUST NOT provide any HELD contexts contain
information to the LIS that it does not
want requires the LIS to know or be able to use in some capacity associated
with determination or providing of same protections.

6.1. Multiple Contexts from the Target's location. 'Same' Target

It is quite conceivable that a LIS will be required to provide location to Targets
Devices residing behind a NAT; a DSL NAT. A home router with 5
PCs attached gateway is a good example this situation. of a
situation where the relatively small geographic area served by the
gateway is adequately served by a LIS external to that network.
Devices within the home network appear to have the same identity
information to a LIS - requests all originate from the same IP
address. In this case it is
reasonable for case, each device to Device might create its own context on
the LIS, and
for the LIS. The LIS to treat treats 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 might be added unable to a context and distinguish between the way actual Devices making
the requests.

It is also possible that a Target single Device could request multiple
contexts. Devices might want to manage expiry separately, a Target may use have multiple users, or multiple contexts as a way to isolate
applications from running that each other.
For instance, a Target can have have different privileges,
different privacy requirements or different Rule Makers. Therefore,
might create a context different contexts for different uses: each application so might a
different policy that it can revoke access reflects the needs of the user or application.
Information provided by a Device related to its location a context MUST NOT be
used by the LIS outside of that context.

The state information for each
without affecting other applications' access. This environment,
however, opens maintained by the LIS to or LS in providing a
context presents 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 vector. Limiting 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 allows to reduced LIS complexity and the amount of
private information that the Target be created can protect
against such attacks. Any limits 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
privacy. Using consider the mechanisms described usage pattern
expected. If home gateways are commonly deployed 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 access
network, then the LIS is a critical
component MUST allow for more than one context for each
discrete identifier. However, to supporting ensure that LIS resources are not
exhausted, the functionality described in this memo.
The LIS MUST follow limit the rules described in Section 5.5 for generating
context identifiers.

8. number of contexts that it permits
from each identifier.

7. IANA Considerations

This document registers the schema and associated namespace with
IANA.

8.1.

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

7.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 6
Section 5 of this document.

8.3. New

7.3. HELD Error Code Registration

Reference: RFC-XXXX Section 4.4 of RFCXXXX (i.e., this document)requires document) specifies the
following new HELD error codes:

badPolicy

unknownContext

contextFailure

These error codes to be and their descriptions are added to the HELD error
code respository defined in
[I-D.ietf-geopriv-http-location-delivery].

Error code: badContextMessage

Error code: unknownContext

Error code: updateContextFailed

Error code: createContextFailed

8. Acknowledgements

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

Thanks also to Tim Zelinski and Michael Diponio , Diponio, who pointed out a
problems while implementing an early revision of this specification.

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

9. References

9.1. Normative References

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

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

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

[RFC4745] Schulzrinne, H.,
Tschofenig, H., Morris,
J., Cuellar, J., Polk, J.,
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 J. Rosenberg, "Common
Policy: A Document Format
for Expressing Privacy
Preferences", RFC 4745,
February 2007.

[I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom,
J., Thomson, M., and 3 were
successful but that extension 2 had a problem B.
Stark, "HTTP Enabled
Location Delivery (HELD)",
draft-ietf-geopriv-http-
location-delivery-13 (work
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, progress),
February 2009.

9.2. Informative References

[RFC3693] Cuellar, J., Morris, J.,
Mulligan, D., Peterson,
J., and authorization policies. The second type of data consists of a
two way exchange between the Target J. Polk, "Geopriv
Requirements", RFC 3693,
February 2004.

[RFC4825] Rosenberg, J., "The
Extensible Markup Language
(XML) Configuration Access
Protocol (XCAP)",
RFC 4825, May 2007.

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

<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 7: 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 H.
Schulzrinne, "GEOPRIV
Layer 7 Location
Configuration Protocol;
Problem Statement and
Requirements", draft-ietf-
geopriv-l7-lcp-ps-09 (work
in the LIS failing to create the context at all.
Regardless, it is mandatory progress),
February 2009.

[I-D.ietf-geopriv-lbyr-requirements] Marshall, R.,
"Requirements 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"
expires="2007-08-01T13:00:00">
<locationUriSet>
<locationURI>
held//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 8: 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
Location-by-Reference
Mechanism", draft-ietf-
geopriv-lbyr-requirements-
07 (work in order to remove information, but this SHOULD be treated
as a last resort progress),
February 2009.

[I-D.ietf-geopriv-lis-discovery] Thomson, M. and not used as the primary mechanism for removing
data from J.
Winterbottom, "Discovering
the context. Local Location
Information Server (LIS)",
draft-ietf-geopriv-lis-
discovery-09 (work in
progress), March 2009.

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

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

High-level requirements for a location configuration protocol.

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

COMPLY.

Compliant: 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 When a location URI
will has a limited
validity interval, its lifetime MUST be valid."

COMPLY. HELD with indicated."

Compliant: All location URIs provided expire; the context management extensions described
in this document provide the Target
response message indicates when the ability to specify
expiry times for location URIs. URI expires.

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

COMPLY. HELD with the

Compliant: Updating a context management extensions described
in this document provide the Target the ability with a lifetime set to void location
URIs when required. zero
cancels a context.

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

COMPLY. The HELD specification form MUST,
through randomization and this document provide uniqueness, ensure that any location
specific guidance on information embedded within the security surrounding location URI
generation. itself is
kept obscure during location configuration."

Compliant: With an explicit reference to this requirement, the
URIs produced for a HELD context are required to comply with
this condition.

C5. "Identity Protection - LCP: "User Identity Protection: The location URI MUST NOT contain
any user identifying information that identifies the user,
device or address of
record record, (e.g., which includes phone
extensions, badge numbers, first or last names, etc.), within
the URI form."
COMPLY. The HELD specification and

Compliant: With an explicit reference to this document provide
specific guidance on the anonymity of requirement, the Target with regards
URIs produced for a HELD context are required to
the generation of location URIs. comply with
this condition.

C6. "Reuse flag default: The LCP indicator: There SHOULD be a way to allow a client to
control whether a location URI can be resolved once only, or
multiple times."

Not compliant.

C7. "Validity Interval Indication: A location configuration
protocol MUST support the default condition provide an indication of a requested the location URI being repeatedly reused."

COMPLY. HELD with
validity interval (i.e., expiry time) when present."

Compliant: The "expires" attribute indicates the time when the
context management extensions described
in this document provide becomes invalid.

C8. "Location only: The location URI MUST NOT point to any
information about the Target other than it's location."

Compliant: PIDF-LO documents that are produced by the ability LS in
response to specify how
many times a request at the URI do not contain Target
identification, unless policy states otherwise.

C9. "Location URI Not guessable: Where location URIs are used
publicly, any location URI may yield MUST be constructed using properties
of uniqueness and cryptographically random sequences so that it
is not guessable. (Note that the location number of Target.

C7. "One-time-use: The LCP MUST support bits depends to
some extent on the ability number of active location URIs that might
exist at the one time; 128-bit is most likely enough for the client
to request a 'one-time-use'
near term.)"

Compliant: Section 4.5 describes how this requirement is met by
implementations.

C10. "Location URI Optional: In the case of user-provided
authorization policies, where anonymous or non-guessable
location URIs are not warranted, the location configuration
protocol MAY support optional location URI (e.g., via a reuse flag
setting)."

COMPLY. HELD with forms."

Not compliant: The format of location URIs generated by the context management extensions LIS
cannot be influenced through any of the parameters described in
this document provide the Target the ability to specify how
many times a location document.

C11. "Location URI may yield Authorization Model: The location configuration
protocol SHOULD indicate whether the requested 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 URI
conforms 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-09 (work the access control authorization model or the
possession authorization model."

Compliant: The authorization model is explicitly selected by
the Device in
progress), September 2008.

[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement the request.

C12. "Location URI Lifetime: A location URI SHOULD have an
associated expiration lifetime (i.e., validity interval), and
Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008.

[I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
in progress), July 2008.
MUST have an validity interval if used with the possession
authorization model."

Duplicate requirement.

Authors' Addresses

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

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

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland

Phone: +358 (50) 4871445
Email:
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at

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

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

Full Copyright Statement

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.