draft-ietf-geopriv-lbyr-requirements-00.txt   draft-ietf-geopriv-lbyr-requirements-01.txt 
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational September 5, 2007 Intended status: Informational October 11, 2007
Expires: March 8, 2008 Expires: April 13, 2008
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-00 draft-ietf-geopriv-lbyr-requirements-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 8, 2008. This Internet-Draft will expire on April 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to a Location-by-Reference approach to handling location information to Location-by-Reference approach to handling location information
within SIP signaling and other Internet messaging. The key for a within signaling and other Internet messaging.
Location-by-Reference mechanism is the Location URI, which is a
reference to a location, and is used by either an end-device or a
middlebox to represent a location, and is used as a key by a
dereferencing protocol to get a usable form of location. An example
application for which the Location-by-Reference mechanism is used is
emergency call routing with voice-over-IP (VoIP) and general Internet
multimedia systems, where Internet protocols are used end-to-end.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 6 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. High-Level Requirements for a Location Configuration 5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 8
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Requirements for a Location Configuration Protocol . . . 8
6. High-Level Requirements for a Location Dereference 5.2. Requirements for a Location Dereference Protocol . . . . 9
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Location-based services rely on ready access to location information, Location-based services rely on ready access to location information,
which can be through a direct, or indirect mechanism. While there is which can be through a direct or indirect mechanism. While there is
already a direct mechanism which exists to provide location as part already a direct mechanism which exists to provide location as part
of the SIP signaling protocol, an alternative mechanism has been of the SIP signaling protocol, an alternative mechanism has been
developed for handling location indirectly, via a location reference, developed for handling location indirectly, via a location reference,
a reference which points to the actual location information. This a reference which points to the actual location information. This
reference is called the location URI, and is used by the Location-by- reference is called the location URI, and is used by the mechanism we
Reference mechanism. call Location-by-Reference, or LbyR.
Since possessing the location URI alone is insufficient to perform
location-based routing, the location URI must be dereferenced. Once
the actual location information is returned to a location recipient,
it can then be used as input to some location-based service, such as
in the case of routing a VoIP-based emergency call.
This document lists a set of requirements for a Location-by-Reference
(LbyR) mechanism, using a location URI within the SIP protocol for
the purpose of executing a location-based service routing request.
There are a variety of actions in which a location URI can be used.
Included in this list is the action of 'location configuration', or
the acquisition of the location into an end device or middlebox,
'location conveyance', which is the shuttling of location between SIP
signaling nodes, and, 'location dereferencing', which we define as
the action of exchanging a location URI for the actual location
information it points to at a dereference server, which we call a
Location Information Server, or LIS.
Each of these actions are represented by specific individual
protocols. A Location Configuration Protocol (LCP), is used by a
device or middlebox to acquire a location which already exists
(examples of this protocol include DHCP, LLDP-MED, and HELD). By
conveyance protocol, we mean a protocol which transports a location
URI along from node to node according to specific rules (e.g., SIP).
A Location Dereferencing Protocol (LDP), is used by a client to
resolve a location URI in exchange for location information at a LIS.
Though conveyance of a location URI may be discussed in general
terms, any requirements for conveyance using LbyR are not included,
and are considered out of scope.
In our SIP example, the LbyR is setup, instead of having a content Each of the actions by which a location URI can be used is
identifier (cid:) pointing to a location object within a SIP body, to represented by specific individual protocol. For example, a Location
have a location URI carried in the SIP Geolocation header. Configuration Protocol, is used by a device or middlebox to acquire a
location which already exists (examples of this protocol include
DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]).
The location configuration protocol problem statement and
requirements document can be found in [I-D.ietf-geopriv-l7-lcp-ps].
The action of conveying a location URI along from node to node
according to specific rules in SIP, for example, is known as a
conveyance protocol. A location dereferencing protocol, is used by a
client to resolve a location URI in exchange for location information
from a dereference server (e.g., a LIS).
In constrast to LbyR, a direct access to location is equivalent to The structure of this document first defines terminology, or points
having a location object included along with the signaling, (e.g., a to the appropriate draft where defined, in Section 3. Then a short
PIDF-LO), is referred to as the Location-by-Value (LbyV) mechanism, discussion on the basic elements which show LbyR. This section on
and is treated as out of scope for this document. A separate draft actors, Section 4 includes a basic model, and describes the steps
document exists which describes, for both LbyR and LbyV scenarios, a which the LbyR mechanism takes.
way to convey location within SIP [I-D.ietf-sip-location-conveyance].
The structure of this document first defines terminology in Requirements are outlined separately for location configuration,
Section 3. Then a short discussion on the basic elements which show Section 5.1, followed by those for a dereferencing protocol,
LbyR. This section on actors, Section 4 includes a basic LbyR model, Section 5.2.
and describes the steps which the LbyR mechanism takes.
Requirements are outlined separately for the configuration step Location-by-Value, called LbyV, in contrast to LbyR, is a direct
(LCP), (Section 5), followed by an additional list of requirements location conveyance approach and includes the location object, e.g.,
targeted toward the dereferencing step (LDP) (Section 6). a PIDF-LO [RFC4119] in the SIP signaling. Location conveyance is out
of scope for this document (see [I-D.ietf-sip-location-conveyance]
for an explanation of conveyance of location including both LbyR and
LbyV scenarios.
Location determination, which may include the processes of manual Location determination, which may include the processes of manual
provisioning, automated measurements, or location transformations, provisioning, automated measurements, or location transformations,
(e.g., geo-coding), are beyond the scope of this document. (e.g., geo-coding), are beyond the scope of this document.
A detailed discussion of Identity information related to the caller, A detailed discussion of Identity information related to the caller,
subscriber, or device, as associated to location or location URI, is subscriber, or device, as associated to location or location URI, is
also out of scope. also out of scope.
2. Requirements Terminology 2. Requirements Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and "OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 2119 [RFC2119].
This document outlines only requirements for an LbyR mechanism which
is used by two different protocols, a Location Configuration
Protocol, and a Location Derferencing Protocol. Each of these
protocols has its own unique client and server interactions, and the
requirements here are not intended to state what either an LCP or LDP
host client or server is expected to do, but rather which
requirements must be met by both the LCP and LDP interface protocols.
3. Terminology 3. Terminology
3.1. Definition of Terms This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Several of the terms presented below are based on Geopriv Location Generator (LG), Location Object (LO), and Using Protocol:
Requirements [RFC3693], and in some cases, extended to include
additional language to support the LbyR model.
Civic location: A described location based on some understood
location reference system, such a jurisdictions or postal delivery
grid. A street address valid within the USPS system is a common
example.
Coordinate location: A reference to a geographic point which is able
to be located as described by a set of defined coordinates within
a geographic coordinate system, such as latitude and longitude,
within the WGS-84 datum. For example, 2-D geographic location is
defined as an (x,y) coordinate value pair according to the
distance north or south of the equator and east or west of the
prime meridian. A coordinate location may be absolute, or may
have associated uncertainty related to it's exact position,
depending on how it is represented.
Location: Either a geographic coordinate or feature representation
based on a specific coordinate reference system, or by other
identifiable information such as a street number and street name
within a civic, postal, or abstract location reference system.
Location-by-Value: The mechanism of representing location either in
configuration or conveyance protocols, (i.e., the actual location
value is included).
Location-by-Reference: The mechanism of representing location either
in configuration, conveyance, and dereferencing protocols as an
identifier which refers to a fully specified location, (i.e., a
pointer to the actual location value).
Location Configuration Protocol (LCP): A protocol which is used by a
client to acquire location or a location URI from a location
configuration server (e.g., (LIS)), based on information unique to
the client.
Location Dereference Protocol (LDP): A protocol which is used by a 3.1. Terms
client to query a location dereference server (e.g., (LIS)), based
on location URI input and which returns location information
(e.g., a PIDF-LO).
Location Information Server (LIS): The entity which receives a Location-by-Value (LbyV): The mechanism of representing location
client request for either location or a location reference. In either in configuration or conveyance protocols, (i.e., the actual
the latter case, also performs the dereference function for a included location value).
Location Refernce Identifier, in the context of the Location-by-
Reference model. May also be referred to as a Location
Information Server (LIS). In the SIP Presence architecture, the
LIS may be referred to as a Presence Server (PS). In this
document the LIS is an instance of an LS.
Location Object (LO): An object conveying location information (and Location-by-Reference (LbyR): The mechanism of representing location
possibly privacy rules) to which Geopriv security mechanisms and either in configuration, conveyance, or in dereferencing protocols
privacy rules are to be applied. as an identifier which refers to a fully specified location,
(i.e., a pointer to the actual location value).
Location Recipient (LR): The entity that receives location Location Configuration Protocol: A protocol which is used by a
information. It may have asked for this location explicitly (by client to acquire either location or a location URI from a
sending a query containing an location URI to a location location configuration server, based on information unique to the
configuration server), or it may receive this location client.
asynchronously.
Location Server (LS): The entity to which a LG publishes location Location Dereference Protocol: A protocol which is used by a client
objects, the recipient of queries from location receivers, and the to query a location dereference server, based on location URI
entity that applies rules designed by the rule maker. input and which returns location information.
Location URI: An identifier which serves as a pointer to a location Location URI: An identifier which serves as a pointer to a location
record on a remote host (e.g., LIS). Used within an Location-by- record on a remote host (e.g., LIS). Used within an Location-by-
Reference (LbyR) mechanism. A location URI is provided by a Reference mechanism, a location URI is provided by a location
location configuration server, based on a client request, and is configuration server, and is used as input by a dereference
the input used by the dereference protocol to retrieve the protocol to retrieve location from a dereference server.
associated location from a dereference server. It is assumed that
a LIS can function both as a configuration server and dereference
server.
Rule Maker (RM): The authority that creates rules governing access
to location information for a target (typically, this it the
target themselves).
Target: A person, end device, or other entity whose location is
communicated by a Geopriv Location Object.
Using Protocol: A protocol (e.g., SIP) which carries a Location
Object or an Location Reference Identifier.
4. Basic Actors 4. Basic Actors
LbyR with Location Subscription
The LbyR mechanism can be used via a normal query/response mode, or
alternatively, by using a subscription model to get updated location.
In mobile wireless networks it is not efficient for the end host to In mobile wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This periodically query the LIS for up-to-date location information. This
is especially the case when power is a constraint or a location is especially the case when power is a constraint or a location
update is not immediately needed. Furthermore, the end host might update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server. Finally, information to a third party, such as to a presence server. Finally,
in some deployments, the network operator may not want to make in some deployments, the network operator may not want to make
location information widely available. location information widely available.
These use scenarios motivated the introduction of the LbyR concept. These use scenarios motivated the introduction of the LbyR concept.
Depending on the type of reference, such as HTTP/HTTPS or SIP Depending on the type of reference, such as HTTP/HTTPS or SIP
Presence URI, different operations can be performed. While an HTTP/ Presence URI, different operations can be performed. While an HTTP/
HTTPS URI can be resolved to location information, a SIP Presence URI HTTPS URI can be resolved to location information, a SIP Presence URI
provides further benefits from the SUBSCRIBE/NOTIFY concept that can provides further benefits from the SUBSCRIBE/NOTIFY concept that can
additionally be combined with location filters additionally be combined with location filters
[I-D.ietf-geopriv-loc-filters]. [I-D.ietf-geopriv-loc-filters].
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | LDP (3) | Location | | | Location | Location |
| LIS +---------------+ Recipient | | LIS +---------------+ Recipient |
| | | | | | Dereference | |
+-----+-----+ +----+------+ +-----+-----+ Protocol (3) +----+------+
| --
| -- | --
| Geopriv -- | Geopriv --
| LCP -- | Location --
| (1) -- | Configuration --
| -- Geopriv | Protocol --
| (1) -- Geopriv
| -- Using Protocol | -- Using Protocol
| -- (e.g., SIP) | -- (e.g., SIP)
+-----+-----+ -- (2) +-----+-----+ -- (2)
| Target / |-- | Target / |--
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 1: Shows the assumed communication model for a layer 7 (L7) Figure 1: Shows the assumed communication model for both a layer 7
LCP and LDP: location configuration protocol and a dereference protocol:
Note that there is no requirement for using the same protocol in (1) Note that there is no requirement for using the same protocol in (1)
and (3). and (3).
The following list describes the location subscription approach: The following list describes the location subscription approach:
1. The end host discovers the LIS. 1. The end host discovers the LIS.
2. The target (end host) sends a request to the LIS asking for a 2. The target (end host) sends a request to the LIS asking for a
location URI, as shown in (1) of Figure 1. location URI, as shown in (1) of Figure 1.
skipping to change at page 9, line 29 skipping to change at page 7, line 26
subscription URI (see (3) of Figure 1) and potentially uses a subscription URI (see (3) of Figure 1) and potentially uses a
location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the
notification rate. notification rate.
5. If the Target moves outside a certain area, indicated by a 5. If the Target moves outside a certain area, indicated by a
location filter, the Location Recipient will receive a notification. location filter, the Location Recipient will receive a notification.
Note that the Target may also act in the role of the Location Note that the Target may also act in the role of the Location
Recipient whereby it would subscribe to its own location information. Recipient whereby it would subscribe to its own location information.
For example, the Target obtains a subscription URI from the Geopriv For example, the Target obtains a subscription URI from the Geopriv
L7 LCP protocol. It subscribes to the URI in order to obtain its L7 Location Configuration Protocol. It subscribes to the URI in
current location information. A service boundary indicates the order to obtain its current location information. A service boundary
bounded extent up to which the device can move without the need to indicates the bounded extent up to which the device can move without
have an updated location, since a re-query with any location within the need to have an updated location, since a re-query with any
the boundary would result in the same answer returned from a location within the boundary would result in the same answer returned
location-based service. from a location-based service.
For LbyR, the LIS needs to maintain a list of randomized location For LbyR, the LIS needs to maintain a list of randomized location
URIs for each host, timing out each of these URIs after the reference URIs for each host, timing out each of these URIs after the reference
expires. Location URIs need to expire to prevent the recipient of expires. Location URIs need to expire to prevent the recipient of
such a URI from being able to (in some cases) permanently track a such a URI from being able to (in some cases) permanently track a
host. Furthermore, an expiration mechanism also offers garbage host. Furthermore, an expiration mechanism also offers garbage
collection capability for the LIS. collection capability for the LIS.
Location URIs must be designed to prevent adversaries from obtaining Location URIs must be designed to prevent adversaries from obtaining
a known Target's location. There are at least two approaches: The a known Target's location. There are at least two approaches: The
location URI contains a random component which helps obscure location URI contains a random component which helps obscure
sequential updates to location, yet still allows any holder of the sequential updates to location, yet still allows any holder of the
location URI to obtain location information. Alternatively, the location URI to obtain location information. Alternatively, the
location URI can remain public and the LIS performs access control location URI can remain public and the LIS performs access control
via a separate authentication mechanism, such as HTTP digest or TLS via a separate authentication mechanism, such as HTTP digest or TLS
client side authentication, when resolving the reference to a client side authentication, when resolving the reference to a
location object. location object.
5. High-Level Requirements for a Location Configuration Protocol 5. High-Level Requirements
This document outlines only requirements for an LbyR mechanism which
is used by two different protocols, a location configuration
protocol, and a location dereferencing protocol. Each of these
protocols has its own unique client and server interactions, and the
requirements here are not intended to state what a client or server
is expected to do, but rather which requirements must be met by
either the configuration or dereferencing protocol itself.
5.1. Requirements for a Location Configuration Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the LCP. location-by-reference mechanism as used within the location
configuration protocol.
C1. Location URI support - LCP: The configuration protocol MUST C1. Location URI support: The configuration protocol MUST support a
support a location reference in URI form. location reference in URI form.
Motivation: It is helpful to have a consistent form of key for the Motivation: It is helpful to have a consistent form of key for the
LbyR mechanism. LbyR mechanism.
C2. Location URI expiration: The LCP MUST support the ability to C2. Location URI expiration: The lifetime of a location URI SHOULD
specify to the server, the length of time that a location URI will be indicated.
be valid.
Motivation: Location URIs are not intended to represent a location Motivation: Location URIs are not intended to represent a location
forever, and the identifier eventually may need to be recycled, or forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is location reference fails to yield a location, or the location is
determined to be kept confidential. A configurable carried in the determined to be kept confidential.
LCP for a location URI ensures that the location reference becomes
invalid based on some internal LIS settings.
C3. Location URI cancellation: The LCP MUST support the ability to C3. Location URI cancellation: The location configuration protocol
request a cancellation of a specific location URI. SHOULD support the ability to request a cancellation of a specific
location URI.
Motivation: If the client determines that in its best interest to Motivation: If the client determines that in its best interest to
destroy the ability for a location URI to effectively be used to destroy the ability for a location URI to effectively be used to
dereference a location, then there has to be a way to nullify the dereference a location, then there should be a way to nullify the
location URI. (This may be accomplished by setting the C2 location URI.
configurable to 'expire=now', for example.)
C4. Random Generated: The location URI MUST be hard to guess, i.e., C4. Random Generated: The location URI MUST be hard to guess, i.e.,
it MUST contain a cryptographically random component. it MUST contain a cryptographically random component.
Motivation: There is some benefit to the client if the location Motivation: There is some benefit to the client if the location
URI is generated in an obscured manner so that its sequence, for URI is generated in an obscured manner so that its sequence, for
example in the case of a client's location update, can't be easy example in the case of a client's location update, can't be easy
guessed. guessed.
C5. Identity Protection - LCP : The location URI MUST NOT contain C5. Identity Protection: The location URI MUST NOT contain any
any information that identifies the user, device or address of information that identifies the user, device or address of record
record within the URI form. within the URI form.
Motivation: It is important to protect caller identity or contact Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself address from being included in the form of the location URI itself
when it is generated. when it is generated.
C6. Reuse flag default: The LCP MUST support the default condition C6. Reuse indicator: There SHOULD be a way to allow a client to
of a requested location URI being repeatedly reused. control whether a location URI can be resolved once or multiple
times.
Motivation: The requestor of a location URI, shouldn't need to
specify any special flag in order to receive a location URI which
can later be used repeatedly, such as for an updated location.
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).
Motivation: The client requesting a location URI may request a Motivation: The client requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. opposed to a location URI having multiple reuse capability.
6. High-Level Requirements for a Location Dereference Protocol C7. Location timestamp: There SHOULD be a way to allow a client to
determine whether the dereferenced location information refers to
the location of the Target at the time when the location URI was
created or when it was dereferenced.
Motivation: It is important to distinguish between an original and
an updated location.
5.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism. location-by-reference mechanism as used within the location
dereference protocol.
D1. Location URI support - LDP: The LDP MUST support a location D1. Location URI support: The location dereference protocol MUST
reference in URI form. support a location reference in URI form.
Motivation: It is required that there be consistency of use Motivation: It is required that there be consistency of use
between location URI formats used in an LCP and those used by a between location URI formats used in an configuration protocol and
LDP. those used by a dereference protocol.
D2. Location URI expiration status: The LDP MUST support a message D2. Location URI expiration status: The location dereference
indicating that for a location URI which is no longer valid, that protocol MUST support a message indicating that for a location URI
the location URI has expired. which is no longer valid, that the location URI has expired.
Motivation: Location URIs are expected to expire, based on LCP Motivation: Location URIs are expected to expire, based on
parameters, and it is therefore useful to convey the expired location configuration protocol parameters, and it is therefore
status of the location URI in the LDP. useful to convey the expired status of the location URI in the
location dereference protocol.
D3. Authentication: The LDP MUST support either client-side and D3. Authentication: The location dereference protocol MUST support
server-side authentication between client and server. either client-side and server-side authentication.
Motivation: It is reasonable to expect implementations of Motivation: It is reasonable to expect implementations of
authentication to vary. Some implementations may choose to authentication to vary. Some implementations may choose to
implement both client-side and server-side authentication, might implement both client-side and server-side authentication, might
implement one only, or may implement neither. implement one only, or may implement neither.
D4. Dereferenced Location Form: Location URI dereferencing MUST D4. Dereferenced Location Form: The dereferenced location MUST
result in a well-formed PIDF-LO. result in a well-formed PIDF-LO.
Motivation: This is in order to ensure both interoperation Motivation: This is in order to ensure that adequate privacy rules
consistancy and that adequate privacy rules can be adhered to, can be adhered to, since the PIDF-LO format comprises the
since the PIDF-LO format comprises the necessary structures to necessary structures to maintain location privacy.
maintain location privacy.
D5. Repeated use: The LDP MUST support the ability for the same
location URI to be resolved more than once, based on server
settings and LCP parameters.
Motivation: According to LCP parameters, there may or may not be a
limit on the number of dereferencing actions at the dereference
server.
D6. Updated location: The LDP MUST support the ability for the same
location URI to be resolved into a continuum of location values
(e.g., location updates).
Motivation: A location URI when reused may not always result in
the same location value, but may be a mixture of unchanged and
changed location values.
D7. Location form: The LDP MUST support dereferenced location in D5. Repeated use: The location dereference protocol MUST support the
both coordinate and civic forms. ability for the same location URI to be resolved more than once,
based on server settings and configuration server parameters.
Motivation: It is important that the LDP not limit which type of Motivation: According to configuration server parameters, it may
location gets dereferenced, since it is assumed that some be necessary to have a limit on the number of dereferencing
dereference servers may provide coordinate form of location only, attempts.
others may provide civic only, while some may provide both forms
of location.
7. Security Considerations 6. Security Considerations
The LbyR mechanism currently addresses security issues as follows. The LbyR mechanism currently addresses security issues as follows.
A location URI, regardless of its randomized construction, if A location URI, regardless of its randomized construction, if
public, implies no safeguard against anyone being able to public, implies no safeguard against anyone being able to
dereference and get the location. The randomization of a location dereference and get the location. The randomization of a location
URI in its naming, does help prevent some potential guessing, URI in its naming does help prevent some potential guessing,
according to some defined pattern. In the instance of one-time- according to some defined pattern. In the instance of one-time-
use location URIs, which function similarly to a pawn ticket, the use location URIs, which function similarly to a pawn ticket, the
argument can be made that with a pawn ticket, possession implies argument can be made that with a pawn ticket, possession implies
permission, and location URIs which are public are protected only permission, and location URIs which are public are protected only
by privacy rules enforced at the dereference server. by privacy rules enforced at the dereference server.
Additional security issues will be discussed in a separate geopriv Additional security issues will be discussed in the geopriv draft,
document. draft-barnes-geopriv-lo-sec-00.txt.
8. IANA Considerations 7. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
9. Acknowledgements 8. Acknowledgements
I would like to thank the IETF GEOPRIV working group chairs, Andy We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating the design Newton, Allison Mankin and Randall Gellens, for creating the design
team which initiated this requirements work. team which initiated this requirements work. We'd also like to thank
those design team participants for their inputs, comments, and
I also would like to thank Andrew Newton; Martin Dawson; Henning reviews. The design team included the following folks: Richard
Schulzrinne; Marc Linsner; Brian Rosen; Ted Hardie; James M. Polk; Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie;
James Winterbottom; Martin Thomson; John Schnizlein; Barbara Stark; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger
Jon Peterson; Allison Mankin; Randall Gellens; Cullen Jennings; Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
Richard Barnes; Keith Drage; Rohan Mahy; and Hannes Tschofenig, for John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
their individual contributions and comments. Tschofenig; Martin Thomson; and James Winterbottom.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 9.2. Informative References
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)", Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
draft-ietf-geopriv-http-location-delivery-01 (work in "HTTP Enabled Location Delivery (HELD)",
progress), July 2007. draft-ietf-geopriv-http-location-delivery-02 (work in
progress), September 2007.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-04 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
progress), August 2007. progress), September 2007.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)", Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress), draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007. March 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-08 (work in progress), draft-ietf-sip-location-conveyance-08 (work in progress),
July 2007. July 2007.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
Appendix A. Change log
Changes to this draft in comparison to the -00 version:
1. Shortened Abstract and Introduction.
2. LDP term gone. Expansion of Location Dereferencing Protocol,
deletion of "LDP" acronym throughout, since LDP stands for Label
Distribution Protocol elsewhere in the IETF.
3. LCP term is also gone. LCP is used as Link Control Protocol
elsewhere (IETF).
4. Reduced the number of terms in the doc. Referenced other drafts
or RFCs for repeated terms.
5. Requirement C2. changed to indicate that the URI has a lifetime.
6. C3. Softened by changing from a MUST to a SHOULD.
7. C6. Reworded for clarity.
8. C7. Changed the MUST to a SHOULD to reflect a more appropriate
level.
9. D6. Replaced the text to make it clearer.
10. D7. Deleted the requirement since it wasn't an appropriate task
for the protocol.
11. Referenced Richard's security document
12. Cleaned up some text.
Author's Address Author's Address
Roger Marshall (editor) Roger Marshall (editor)
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
2401 Elliott Avenue 2401 Elliott Avenue
2nd Floor 2nd Floor
Seattle, WA 98121 Seattle, WA 98121
US US
Phone: +1 206 792 2424 Phone: +1 206 792 2424
 End of changes. 58 change blocks. 
283 lines changed or deleted 211 lines changed or added

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