draft-ietf-geopriv-lbyr-requirements-09.txt   rfc5808.txt 
GeoPriv R. Marshall, Ed. Internet Engineering Task Force (IETF) R. Marshall, Ed.
Internet-Draft TCS Request for Comments: 5808 TCS
Intended status: Informational November 9, 2009 Category: Informational May 2010
Expires: May 13, 2010 ISSN: 2070-1721
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-09
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location Uniform Resource to the Location-by-Reference approach using a location Uniform
Identifier (URI) to handle location information within signaling and Resource Identifier (URI) to handle location information within
other Internet messaging. signaling and other Internet messaging.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with 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 Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on May 13, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5808.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology .....................................................5
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 9 3. Overview of Location-by-Reference ...............................6
3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 10 3.1. Location URI Usage .........................................7
3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 10 3.2. Location URI Expiration ....................................8
3.3. Location URI Authorization . . . . . . . . . . . . . . . . 11 3.3. Location URI Authorization .................................8
3.4. Location URI Construction . . . . . . . . . . . . . . . . 11 3.4. Location URI Construction ..................................9
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 13 4. High-Level Requirements .........................................9
4.1. Requirements for a Location Configuration Protocol . . . . 13 4.1. Requirements for a Location Configuration Protocol .........9
4.2. Requirements for a Location Dereference Protocol . . . . . 15 4.2. Requirements for a Location Dereference Protocol ..........11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations ........................................12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements ...............................................13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. References .....................................................13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References ......................................13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References ....................................13
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
All location-based services rely on ready access to location All location-based services rely on ready access to location
information. Using location information can be done one of two ways, information. Location information can be used in either a direct,
either in a direct, Location-by-Value (LbyV) approach, or using an Location-by-Value (LbyV) approach or an indirect, Location-by-
indirect, Location-by-Reference (LbyR) model. Reference (LbyR) approach.
For LbyV, location information is conveyed directly in the form of a For LbyV, location information is conveyed directly in the form of a
Presence Information Data Format-Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO) [RFC4119].
([RFC4119]). Using LbyV might either be infeasible or undesirable in Using LbyV might be either infeasible or undesirable in some
some circumstances. There are cases where LbyR is better able to circumstances. There are cases where LbyR is better able to address
address location requirements for a specific architecture or location requirements for a specific architecture or application.
application. This document provides a list of requirements for use This document provides a list of requirements for use with the LbyR
with the LbyR approach, and leaves the LbyV model explicitly out of approach, and leaves the LbyV model explicitly out of scope.
scope.
As justification for a LbyR model, consider the circumstance that in As justification for an LbyR model, consider the circumstance that in
some mobile networks it is not efficient for the end host to some mobile networks it is not efficient for the end host to
periodically query the Location Information Server (LIS) for up-to- periodically query the Location Information Server (LIS) for up-to-
date location information. This is especially the case when power date location information. This is especially the case when power
availability is a constraint or when a location update is not availability is a constraint or when a location update is not
immediately needed. Furthermore, the end host might want to delegate immediately needed. Furthermore, the end host might want to delegate
the task of retrieving and publishing location information to a third the task of retrieving and publishing location information to a third
party, such as to a presence server. Additionally, in some party, such as to a presence server. Additionally, in some
deployments, the network operator may not want to make location deployments, the network operator may not want to make location
information widely available. These kinds of location scenarios form information widely available. These kinds of location scenarios form
the basis of motivation for the LbyR model. the basis of motivation for the LbyR model.
The concept of an LbyR mechanism is simple. An LbyR is made up of a The concept of an LbyR mechanism is simple. An LbyR is made up of a
URI scheme, a domain and a randomized component. This combination of URI scheme, a domain, and a randomized component. This combination
data elements, in the form of a URI, is referred to specifically as a of data elements, in the form of a URI, is referred to specifically
"location URI". as a "location URI".
A location URI is thought of as a reference to the current location A location URI is thought of as a reference to the current location
of the Target, yet the location value might remain unchanged over of the Target, yet the location value might remain unchanged over
specific intervals of time for several reasons. The type of location specific intervals of time for several reasons. The type of location
information returned as part of the dereferencing step may, for information returned as part of the dereferencing step may, for
example, be influenced by the following factors: example, be influenced by the following factors:
- Limitations in the process used to generate location information - Limitations in the process used to generate location information
mean that cached location might be used. mean that cached location might be used.
- Policy constraints that may dictate that the location provided - Policy constraints may dictate that the location provided remains
remains fixed over time for specified Location Recipients. Without fixed over time for specified Location Recipients. Without
additional information, a Location Recipient cannot assume that the additional information, a Location Recipient cannot assume that the
location information provided by any location URI is static, and will location information provided by any location URI is static, and
never change. will never change.
The LbyR mechanism works according to an information lifecycle. The LbyR mechanism works according to an information life cycle.
Within this lifecycle, location URIs are considered temporary Within this life cycle, location URIs are considered temporary
identifiers, each undergoing the following uses: Creation; identifiers, each undergoing the following uses: Creation;
Distribution; Conveyance; Dereference; and Termination. The use of a Distribution; Conveyance; Dereference; and Termination. The use of a
location URI according to these various states is generally applied location URI according to these various states is generally applied
in one of the following ways: in one of the following ways:
1. Creation of a location URI, within a location server, based on 1. Creation of a location URI, within a location server, based on
some request for its creation. some request for its creation.
2. Distribution of a location URI, via a Location Configuration 2. Distribution of a location URI, via a Location Configuration
Protocol, between a Target and a location server. Protocol, between a Target and a location server.
3. Conveyance, applied to LbyR, for example in SIP (Session 3. Conveyance, applied to LbyR, for example in SIP (Session
Inititiation Protocol), is the transporting of the location URI, in Initiation Protocol), is the transporting of the location URI, in
this case, between any successive signaling nodes. this case, between any successive signaling nodes.
4. Dereference of a location URI, a request/response between a 4. Dereference of a location URI, a request/response between a
client having a location URI and a location server holding the client having a location URI and a location server holding the
location information that the location URI references. location information that the location URI references.
5. Termination of a location URI, either due to expiration or 5. Termination of a location URI, due to either expiration or
cancellation within a location server, and which is based on a Target cancellation within a location server, and that is based on a
cancellation request or some other action, such as timer Target cancellation request or some other action, such as timer
expiration. expiration.
Note that this document makes no functional differentiation between a Note that this document makes no functional differentiation between a
Location Server (LS), per [RFC3693], and a Location Information Location Server (LS), per [RFC3693], and a Location Information
Server (LIS), as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may Server (LIS), as shown in [RFC5687], but may refer to either of them
refer to either of them as a location server interchangeably. as a location server interchangeably.
Location determination, as distinct from location configuration or Location determination, as distinct from location configuration or
dereferencing, often includes topics related to manual provisioning dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo- measurement techniques, and/or location transformations (e.g., geo-
coding), and is beyond the scope of this document. coding), and is beyond the scope of this document.
Location Conveyance for either LbyR or LbyV, as defined within SIP Location Conveyance for either LbyR or LbyV, as defined within SIP
signaling is considered out of scope for this document (see signaling is considered out of scope for this document. (See
[I-D.ietf-sip-location-conveyance] for an explanation of location [LOC-CONVEY] for an explanation of location conveyance for either
conveyance for either LbyR or LbyV scenarios.) LbyR or LbyV scenarios.)
Except for location conveyance, the above stages in the LbyR Except for location conveyance, the above stages in the LbyR life
lifecycle fall into one of two general categories of protocols, cycle fall into one of two general categories of protocols, either a
either a Location Configuration Protocol or a Location Dereference Location Configuration Protocol or a Location Dereference Protocol.
Protocol. The stages of LbyR Creation, Distribution, and The stages of LbyR Creation, Distribution, and Termination, are each
Termination, are each found within the set of Location Configuration found within the set of Location Configuration Protocols (LCPs). The
Protocols (LCP). The Dereference stage belongs solely to the set of Dereference stage belongs solely to the set of Location Dereference
Location Dereference Protocols. Protocols.
The issues around location configuration protocols have been The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are requirements document [RFC5687]. There are currently several
currently several examples of documented location configuration examples of documented location configuration protocols, namely DHCP
protocols, namely DHCP DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option], [DHCP-LOC-URI], LLDP-MED [LLDP-MED], and HELD [HELD].
LLDP-MED [LLDP-MED], and HELD HELD
[I-D.ietf-geopriv-http-location-delivery] protocols.
For dereferencing of a location URI, depending on the type of For dereferencing a location URI, depending on the type of reference
reference used, such as a HTTP/HTTPS, or SIP Presence URI, different used, such as a HTTP/HTTPS or SIP Presence URI, different operations
operations can be performed. While an HTTP/HTTPS URI can be resolved can be performed. While an HTTP/HTTPS URI can be resolved to
to location information, a SIP Presence URI provides further benefits location information, a SIP Presence URI provides further benefits
from the SUBSCRIBE/NOTIFY concept that can additionally be combined from the SUBSCRIBE/NOTIFY concept that can additionally be combined
with location filters [I-D.ietf-geopriv-loc-filters]. with location filters [LOC-FILTERS].
The structure of this document includes terminology, Section 2, The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements that surround how a followed by a discussion of the basic elements that surround how a
location URI is used. These elements, or actors, are discussed in an location URI is used. These elements, or actors, are discussed in an
overview section, Section 3, accompanied by a graph, associated overview section, Section 3, accompanied by a graph, associated
processing steps, and a brief discussion around the use, expiration, processing steps, and a brief discussion around the use, expiration,
authorization, and construction of location URIs. authorization, and construction of location URIs.
Requirements are outlined accordingly, separated as location Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference configuration requirements, Section 4.1, and location dereference
skipping to change at page 8, line 16 skipping to change at page 5, line 43
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119], document are to be interpreted as described in RFC 2119 [RFC2119],
with the important qualification that, unless otherwise stated, these with the important qualification that, unless otherwise stated, these
terms apply to the design of the Location Configuration Protocol and terms apply to the design of the Location Configuration Protocol and
the Location Dereferencing Protocol, not its implementation or the Location Dereferencing Protocol, not its implementation or
application. application.
This document reuses the terminology of [RFC3693], such as Location This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Server (LS), Location Recipient (LR), Rule Maker (RM), Target, and
Location Object (LO). Furthermore, the following terms are defined Location Object (LO). Furthermore, the following terms are defined
in this document: in this document:
Location-by-Value (LbyV): Using location information in the form of Location-by-Value (LbyV): Using location information in the form of a
a location object (LO), such as a PIDF-LO. location object (LO), such as a PIDF-LO.
Location-by-Reference (LbyR): Representing location information Location-by-Reference (LbyR): Representing location information
indirectly using a location URI. indirectly using a location URI.
Location Configuration Protocol: A protocol that is used by a Target Location Configuration Protocol: A protocol that is used by a Target
to acquire either location object or a location URI from a to acquire either a location object or a location URI from a
location configuration server, based on information unique to the location configuration server, based on information unique to the
Target. Target.
Location Dereference Protocol: A protocol that is used by a client Location Dereference Protocol: A protocol that is used by a client to
to query a location server, based on the location URI input and query a location server, based on the location URI input, and that
which returns location information. returns location information.
Location URI: As defined within this document, an identifier that Location URI: As defined within this document, an identifier that
serves as a reference to location information. A location URI is serves as a reference to location information. A location URI is
provided by a location server, and is later used as input by a provided by a location server, and is later used as input by a
dereference protocol to retrieve location information. dereference protocol to retrieve location information.
3. Overview of Location-by-Reference 3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the This section describes the entities and interactions involved in the
LbyR model. LbyR model.
+---------+---------+ Location +-----------+ +---------+---------+ Location +-----------+
skipping to change at page 9, line 30 skipping to change at page 6, line 44
(1) | | Rule | | Protocol (1) | | Rule | | Protocol
| | Maker | | (2) | | Maker | | (2)
+----+----+ +---------+ | +----+----+ +---------+ |
| | | | | |
| Target +-------------------------------+ | Target +-------------------------------+
| | | |
+---------+ +---------+
Figure 1: Location Reference Entities and Interactions Figure 1: Location Reference Entities and Interactions
Figure 1 shows the assumed communication model for both a layer 7 Figure 1 shows the assumed communication model for both a Layer 7
location configuration protocol and a location dereference protocol. location configuration protocol and a location dereference protocol.
1. The Target (an end device) uses a Location Configuration Protocol (1) The Target (an end device) uses a location configuration protocol
to acquire a location reference from a LIS, which acts as (or is able to acquire a location reference from a LIS, which acts as (or is
to access) an LS. able to access) an LS.
In the case where the Target is also a Rule Maker, the location In the case where the Target is also a Rule Maker, the location
configuration protocol can be used to convey policy information. In configuration protocol can be used to convey policy information.
the case where possession of a location URI is the only required form
of authorization, see Section 3.3, a policy is implied whereby any
requester is granted access to location information. This does not
preclude other means of providing authorization policies.
A Target could also acquire a location URI from the LS directly using In the case where possession of a location URI is the only
alternative means, for example, the acquisition of a presence AoR to required form of authorization (see Section 3.3), a policy is
be used for location information, in which case, it could be regarded implied whereby any requester is granted access to location
as a location URI. information. This does not preclude other means of providing
authorization policies.
2. The Target conveys the location URI to the Location Recipient A Target could also acquire a location URI from the LS directly
(interface out of scope). using alternative means, for example, the acquisition of a
presence Address of Record (AoR) to be used for location
information, in which case, it could be regarded as a location
URI.
3. The Location Recipient dereferences the location URI to acquire (2) The Target conveys the location URI to the Location Recipient
location information from the LS. (interface out of scope).
(3) The Location Recipient dereferences the location URI to acquire
location information from the LS.
The LS controls access to location information based on the policy The LS controls access to location information based on the policy
provided by the Rule Maker. provided by the Rule Maker.
Note A. There is no requirement for using the same protocol in (1) Note A. There is no requirement for using the same protocol in (1)
and (3). and (3).
Note B. Figure 1 includes the interaction between the owner of the Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to obtain Rule Maker policies. This interaction Target and the LIS to obtain Rule Maker policies. This
needs to happen before the LIS will authorize anything other than interaction needs to happen before the LIS will authorize
what is allowed based on default policies in order to dereference a anything other than what is allowed based on default
location request of the Target. This communication path is out of policies in order to dereference a location request of the
scope for this document. Target. This communication path is out of scope for this
document.
Note C. The Target might take on the role of the Location Recipient, Note C. The Target might take on the role of the Location Recipient,
in which case it could attempt to dereference the location URI in which case, it could attempt to dereference the location
itself, in order to obtain its own location information. URI itself, in order to obtain its own location information.
3.1. Location URI Usage 3.1. Location URI Usage
An example scenario of how the above location configuration and An example scenario of how the above location configuration and
location dereference steps might work using SIP, is where a Target location dereference steps might work using SIP is where a Target
obtains a location URI in the form of a subscription URI (e.g., a SIP obtains a location URI in the form of a subscription URI (e.g., a SIP
URI) via a location configuration protocol. In this case, the Target URI) via a location configuration protocol. In this case, the Target
is the same as the Recipient, therefore the Target can subscribe to is the same as the Recipient; therefore, the Target can subscribe to
the URI in order to be notified of its current location based on the URI in order to be notified of its current location based on
subscription parameters. In the example, parameters are set up for a subscription parameters. In the example, parameters are set up for a
specific Target/Recipient along with an expressed geospatial specific Target/Recipient along with an expressed geospatial
boundary, so that the Target/Recipient receives an updated location boundary, so that the Target/Recipient receives an updated location
notification once the boundary is crossed (see notification once the boundary is crossed (see [LOC-FILTERS]).
[I-D.ietf-geopriv-loc-filters]).
3.2. Location URI Expiration 3.2. Location URI Expiration
Location URIs may have an expiry associated with them, primarily for Location URIs may have an expiry associated with them, primarily for
security considerations, and generally so that the LIS is able to security considerations, and generally in order for the LIS to keep
keep track of the location URIs that have been handed out, to know track of the location URIs that have been handed out, to know whether
whether a location URI is still valid once the LIS receives it in a a location URI is still valid once the LIS receives it in a request,
request, and in order for a recipient of such a URI from being able and for preventing a recipient of such a URI from being able to (in
to (in some cases) permanently track a host. Expiration of a some cases) permanently track a host. Expiration of a location URI
location URI limits the time that accidental leaking of a location limits the time that accidental leaking of a location URI introduces.
URI introduces. Other justifications for expiration of location URIs Other justifications for expiration of location URIs include the
include the ability for a LIS to do garbage collection. ability for a LIS to do garbage collection.
3.3. Location URI Authorization 3.3. Location URI Authorization
How a location URI will ultimately be used within the dereference How a location URI will ultimately be used within the dereference
step is an important consideration at the time the location URI is step is an important consideration at the time the location URI is
requested via a location configuration protocol. The process of requested via a location configuration protocol. The process of
dereferencing location URIs will be influenced by the specific dereferencing location URIs will be influenced by the specific
authorization model applied by the Location Information Server and authorization model applied by the Location Information Server and
the URI scheme that indicates the protocol to be used to resolve the the URI scheme that indicates the protocol to be used to resolve the
reference to a location object. reference to a location object.
Location URIs manifest themselves in a few different forms. The Location URIs manifest themselves in a few different forms. The
different ways that a location URI can be represented is based on different ways that a location URI can be represented are based on
local policy, and are depicted in the following four scenarios. local policy, and are depicted in the following four scenarios.
1. No location information included in the URI: As is typical, a 1. No location information included in the URI: As is typical, a
location URI is used to get location information. However, in location URI is used to get location information. However, in
this case, the URI representation itself does not need to reveal this case, the URI representation itself does not need to reveal
any specific information at all. Location information is acquired any specific information at all. Location information is
by the dereferencing operation using a location URI. acquired by the dereferencing operation using a location URI.
2. URI does not identify a Target: By default, a location URI MUST 2. URI does not identify a Target: By default, a location URI MUST
NOT reveal any information about the Target other than location NOT reveal any information about the Target other than location
information. This is true for the URI itself, (or in the document information. This is true for the URI itself (or in the document
acquired by dereferencing), unless policy explicitly permits acquired by dereferencing), unless policy explicitly permits
otherwise. otherwise.
3. Access control authorization model: If the "access control 3. Access control authorization model: If this model is used, the
authorization model" is used, the location URI MUST NOT include location URI MUST NOT include any location information in its
any location information in its representation. Location URIs representation. Location URIs operating under this model could
operating under this model could be widely published to recipients be widely published to recipients that are not authorized to
that are not authorized to receive this information. receive this information.
4. Possession authorization model (the URI itself is a secret): If 4. Possession authorization model (the URI itself is a secret): If
the "possession authorization" model is used, the location URI is this model is used, the location URI is confidential information
confidential information shared between the LIS/LS, the Target and shared between the LIS/LS, the Target, and all authorized
all authorized Location Recipients. In this case, possession Location Recipients. In this case, possession implies
implies authorization. Because knowledge of the location URI is authorization. Because knowledge of the location URI is used to
used to authenticate and authorize access to location information, authenticate and authorize access to location information, the
the URI needs to include sufficient randomness to make guessing URI needs to include sufficient randomness to make guessing its
its value difficult. A possession model URI can include location value difficult. A possession model URI can include location
information in its representation. information in its representation.
3.4. Location URI Construction 3.4. Location URI Construction
Given scenarios 2 and 4, above, and depending on local policy, a Given scenarios 2 and 4, above, and depending on local policy, a
location URI may be constructed in such a way as to make it difficult location URI may be constructed in such a way as to make it difficult
to guess. Accordingly, the form of the URI is then constrained by to guess. Accordingly, the form of the URI is then constrained by
the degree of randomness and uniqueness applied to it. In this case, the degree of randomness and uniqueness applied to it. In this case,
it may be important to protect the actual location information from it may be important to protect the actual location information from
inspection by an intermediate node. Construction of a location URI inspection by an intermediate node. Construction of a location URI
in such a way as to not reveal any Target specific, (e.g., user or in such a way as to not reveal any Target-specific information (e.g.,
device), information, with the goal of making the location URI appear user or device information), with the goal of making the location URI
bland, uninteresting, and generic, may be helpful to some degree in appear bland, uninteresting, and generic, may be helpful to some
order to keep location information more difficult to detect. Thus, degree in order to keep location information more difficult to
obfuscating the location URI in this way may provide some level of detect. Thus, obfuscating the location URI in this way may provide
safeguard against the undetected stripping off of what would some level of safeguard against the undetected inspection and
otherwise be evident location information, since it forces a unintended use of what would otherwise be evident location
dereference operation at the location dereference server, an information, since it forces a dereference operation at the location
important step for the purpose of providing statistics, audit trails, dereference server, an important step for the purpose of providing
and general logging for many different kinds of location based statistics, audit trails, and general logging for many different
services. kinds of location-based services.
4. High-Level Requirements 4. High-Level Requirements
This document outlines the requirements for an Location by Reference This document outlines the requirements for a Location by Reference
mechanism which can be used by a number of underlying protocols. mechanism that can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location general location configuration protocol and a general location
dereferencing protocol. dereferencing protocol.
The requirements are broken into two sections. The requirements are broken into two sections.
4.1. Requirements for a Location Configuration Protocol 4.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 location location-by-reference mechanism as used within the location
configuration protocol. configuration protocol.
C1. Location URI support: The location configuration protocol MUST C1. Location URI support: The location configuration protocol MUST
support a location reference in URI form. support a location reference in URI form.
Motivation: A standardized location reference mechanism increases Motivation: A standardized location reference mechanism increases
interoperability. interoperability.
C2. Location URI expiration: When a location URI has a limited C2. Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated. validity interval, its lifetime MUST be indicated.
Motivation: A location URI may not intend to represent a location Motivation: A location URI may not intend 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,
may be subject to a specific window of validity, after which the or may be subject to a specific window of validity, after which
location reference fails to yield a location, or the location is the location reference fails to yield a location, or the location
determined to be kept confidential. is determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI. location URI.
Motivation: If the Target determines that a location URI should no Motivation: If the Target determines that a location URI should
longer be used to dereference a location, then there should be a no longer be used to dereference a location, then there should be
way to request that the location URI be nullified." a way to request that the location URI be nullified.
C4. Location Information Masking: The location URI MUST ensure, by C4. Location information masking: The location URI MUST ensure, by
default, through randomization and uniqueness, that the location default, through randomization and uniqueness, that the location
URI does not contain location information specific components. URI does not contain location-information-specific components.
Motivation: It is important to keep any location information Motivation: It is important to keep any location information
masked from a casual observing node. masked from a casual observing node.
C5. Target Identity Protection: The location URI MUST NOT contain C5. Target identity protection: The location URI MUST NOT contain
information that identifies the Target (e.g., user or device). information that identifies the Target (e.g., user or device).
Examples include phone extensions, badge numbers, first or last Examples include phone extensions, badge numbers, and first or
names. last names.
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
when it is generated. itself when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a Target to C6. Reuse indicator: There SHOULD be a way to allow a Target to
control whether a location URI can be resolved once only, or control whether a location URI can be resolved once only or
multiple times. multiple times.
Motivation: The Target requesting a location URI may request a Motivation: The Target requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI that has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. This opposed to a location URI having multiple reuse capability. This
would allow the server to return an error with or without location would allow the server to return an error with or without
information during the subsequent dereference operation. location information during the subsequent dereference operation.
C7. Selective disclosure: The location configuration protocol MUST C7. Selective disclosure: The location configuration protocol MUST
provide a mechanism that allows the Rule Maker to control what provide a mechanism that allows the Rule Maker to control what
information is being disclosed about the Target. information is being disclosed about the Target.
Motivation: The Rule Maker has to be in control of how much Motivation: The Rule Maker has to be in control of how much
information is revealed during the dereferencing step as part of information is revealed during the dereferencing step as part of
the privacy features. the privacy features.
C8. Location URI Not guessable: As a default, the location C8. Location URI not guessable: As a default, the location
configuration protocol MUST return location URIs that are random configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI with and unique throughout the indicated lifetime. A location URI
128-bits of randomness is RECOMMENDED. with 128 bits of randomness is RECOMMENDED.
Motivation: Location URIs should be constructed in such a way that Motivation: Location URIs should be constructed in such a way
an adversary cannot guess them and dereference them without having that an adversary cannot guess them and dereference them without
previously obtained them from the Target. having previously obtained them from the Target.
C9. Location URI Options: In the case of user-provided authorization C9. Location URI options: In the case of user-provided authorization
policies, where anonymous or non-guessable location URIs are not policies, where anonymous or non-guessable location URIs are not
warranted, the location configuration protocol MAY support a warranted, the location configuration protocol MAY support a
variety of optional location URI conventions, as requested by a variety of optional location URI conventions, as requested by a
Target to a location configuration server, (e.g., embedded Target to a location configuration server (e.g., embedded
location information within the location URI). location information within the location URI).
Motivation: Users don't always have such strict privacy Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or requirements, but may opt to specify their own location URI or
components to be included within a location URI. components to be included within a location URI.
4.2. Requirements for a Location Dereference Protocol 4.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 as used within the location location-by-reference mechanism as used within the location
dereference protocol. dereference protocol.
D1. Location URI support: The location dereference protocol MUST D1. Location URI support: The location dereference protocol MUST
support a location 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 a configuration protocol and between location URI formats used in a configuration protocol and
those used by a dereference protocol. those used by a dereference protocol.
D2. Authentication: The location dereference protocol MUST include D2. Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server. mechanisms to authenticate both the client and the server.
Motivation: Although the implementations must support Motivation: Although the implementations must support
authentication of both parties, any given transaction has the authentication of both parties, any given transaction has the
option not to authenticate one or both parties. option not to authenticate one or both parties.
D3. Dereferenced Location Form: The value returned by the D3. Dereferenced location form: The value returned by the dereference
dereference protocol MUST contain a well-formed PIDF-LO document. protocol MUST contain a well-formed PIDF-LO document.
Motivation: This is in order to ensure that adequate privacy rules Motivation: This is in order to ensure that adequate privacy
can be adhered to, since the PIDF-LO format comprises the rules can be adhered to, since the PIDF-LO format comprises the
necessary structures to maintain location privacy. necessary structures to maintain location privacy.
D4. Location URI Repeated Use: The location dereference protocol D4. Location URI repeated use: The location dereference protocol MUST
MUST support the ability for the same location URI to be resolved support the ability for the same location URI to be resolved more
more than once, based on dereference server configuration. than once, based on dereference server configuration.
Motivation: Through dereference server configuration, for example, Motivation: Through dereference server configuration, for
it may be useful to not only allow more than one dereference example, it may be useful to not only allow more than one
request, but, in some cases, to also limit the number of dereference request, but, in some cases, to also limit the number
dereferencing attempts by a client. of dereferencing attempts by a client.
D5. Location Confidentiality: The location dereference protocol MUST D5. Location confidentiality: The location dereference protocol MUST
support confidentiality protection of messages sent between the support confidentiality protection of messages sent between the
Location Recipient and the location server. Location Recipient and the location server.
Motivation: The location URI indicates what type of security Motivation: The location URI indicates what type of security
protocol has to be provided. An example is a location URI using a protocol has to be provided. An example is a location URI using
HTTPS URI scheme. a HTTPS URI scheme.
5. Security Considerations 5. Security Considerations
The method of constructing the location URI to include randomized The method of constructing the location URI to include randomized
components helps to prevent adversaries from obtaining location components helps to prevent adversaries from obtaining location
information without ever retrieving a location URI. In the information without ever retrieving a location URI. In the
possession model, a location URI, regardless of its construction, if possession model, a location URI, regardless of its construction, if
made publically available, implies no safeguard against anyone being made publicly available, implies no safeguard against anyone being
able to dereference and get the location. Care has to be paid when able to dereference and get the location. Care has to be paid when
distributing such a location URI to the trusted location recipients. distributing such a location URI to the trusted location recipients.
When this aspect is of concern then the authorization model has to be When this aspect is of concern, the authorization model has to be
chosen. Even in this model care has to be taken on how to construct chosen. Even in this model, care has to be taken on how to construct
the authorization policies to ensure that only those parties have the authorization policies to ensure that only those parties have
access to location information that are considered trustworthy enough access to location information that are considered trustworthy enough
to enforce the basic rule set that is attached to location to enforce the basic rule set that is attached to location
information in a PIDF-LO document. information in a PIDF-LO document.
Any location URI, by necessity, indicates the server (name) that Any location URI, by necessity, indicates the server (name) that
hosts the location information. Knowledge of the server in some hosts the location information. Knowledge of the server in some
specific domain could therefore reveal something about the location specific domain could therefore reveal something about the location
of the Target. This kind of threat may be mitigated somewhat by of the Target. This kind of threat may be mitigated somewhat by
introducing another layer of indirection: namely the use of a introducing another layer of indirection: namely the use of a
(remote) presence server. (remote) presence server.
A covert channel for protocol message exchange is an important A covert channel for protocol message exchange is an important
consideration, given an example scenario where user A subscribes to consideration, given an example scenario where user A subscribes to
location information for user B, then every time A gets a location location information for user B, then every time A gets a location
update an (external) observer of the subscription notification may update, an (external) observer of the subscription notification may
know that B has moved. One mitigation to this is to have periodic know that B has moved. One mitigation of this is to have periodic
notification, so that user B may appear to have moved, even when notification, so that user B may appear to have moved even when
static. static.
6. IANA Considerations 6. Acknowledgements
This document does not require actions by the IANA.
7. Acknowledgements
I would like to thank the present IETF GEOPRIV working group chairs, I would like to thank the present IETF GEOPRIV working group chairs,
Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy
Newton, Allison Mankin and Randall Gellens, who established a design Newton, Allison Mankin, and Randall Gellens, who established a design
team that initiated this requirements work. I'd also like to thank team that initiated this requirements work. I'd also like to thank
those original design team participants for their inputs, comments, those original design team participants for their inputs, comments,
and insightful reviews. The design team included the following and insightful reviews. The design team included the following
folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; folks: Richard Barnes, Martin Dawson, Keith Drage, Randall Gellens,
Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Ted Hardie, Cullen Jennings, Marc Linsner, Rohan Mahy, Allison
Mankinl; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; Mankin, Andrew Newton, Jon Peterson, James M. Polk, Brian Rosen, John
John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes Schnizlein, Henning Schulzrinne, Barbara Stark, Hannes Tschofenig,
Tschofenig; Martin Thomson; and James Winterbottom. Martin Thomson, and James Winterbottom.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work
in progress), September 2009.
[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-16 (work in
progress), August 2009.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009.
[I-D.ietf-geopriv-loc-filters]
Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in the Session Initiation Protocol
(SIP)", draft-ietf-geopriv-loc-filters-08 (work in
progress), November 2009.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009.
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
Appendix A. Change log
Changes to this draft in comparison to the previous version (-09 vs.
-08), as part of the IESG review process:
1. clarification of missing text, Introduction, (from Alexey
Melnikov), change from: "ower", to "power" (as appropriate) text now
reads, "This is especially the case when power availability is a
constraint"
2. clarify text, Introduction, (from Spencer Dawkins, 06/03/2009),
change from: "Location determination, different than location
configuration" change to: "Location determination, as distinct from
location configuration"
3. insert text, Terminology section, (from Spencer Dawkins, 06/03/
2009), change from: "to acquire either location or a location URI"
change to: "to acquire either location object or a location URI"
4. reword, section 3.3. Location URI Authorization, (from Spencer
Dawkins, 06/03/2009), change from: "1. No specific information at
all:" change to: "1. No location information included in the URI:"
5. rephrase, (overlay new term), section 3.3. Location URI
Authorization, (from Spencer Dawkins, 06/03/2009), Change from: "2.
No Target specific information:" Change to: "2. URI does not
identify a Target:"
6. Add text ahead of paragraph, section titled, "Location URI
Construction", (from Spencer Dawkins, 06/03/2009), change from:
"Depending on local policy," change to: "Given scenarios 2 and 4,
above, and depending on local policy"
7. reword Motivation text, req. C3, (from Spencer Dawkins, 06/03/
2009), change from: "Motivation: If the Target determines that in its
best interest to destroy the ability for a location URI to
effectively be used to dereference a location, then there should be a
way to nullify the location URI." change to: "Motivation: If the
Target determines that a location URI should no longer be used to
dereference a location, then there should be a way to request that
the location URI be nullified."
8. reword requirement C7, (from Spencer Dawkins, 06/03/2009), "C7.
Selective disclosure: The location configuration protocol MUST
provide a mechanism to control what information is being disclosed
about the Target." Change to: "C7. Selective disclosure: The
location configuration protocol MUST provide a mechanism that allows
the Rule Maker to control what information is being disclosed about
the Target."
9. replace text s/ever/previously, (from Spencer Dawkins, 06/03/
2009), change from: "Motivation: Location URIs should be constructed
in such a way that an adversary cannot guess them and dereference
them without having ever obtained them from the Target." change to:
"Motivation: Location URIs should be constructed in such a way that
an adversary cannot guess them and dereference them without having
previously obtained them from the Target."
10. minor fix, section 4.2, D1., s/in an/in a/1 (from Spencer
Dawkins, 06/03/2009),
11. minor fix, section 5. Security Considerations, (from Spencer
Dawkins, 06/03/2009), change from: "when distribution such" change
to: "when distributing such"
12. qualifying text inserted, req. C4 (from Tin Tsou, Ops Review 10/
21/2009) change from: "The location URI MUST, through randomization
and uniqueness, ensure that the location URI does not contain
location information specific components. change to: "The location
URI MUST ensure, by default, through randomization and uniqueness,
that the location URI does not contain location information specific
components.
13. resolve comments from Tina Tsou relating to C4 vs. C9
compatibility,
14. resolve comments from Lisa Dusseault relating to LIS/LS
references and note
Changes to this draft in comparison to the previous version (-08 vs.
-07), as part of the IESG review process:
1. changes sent 09/02/2009 based on IESG Security comments from
Hilarie Orman, 06/08/2009.
2. changes sent 09/02/2009 based on Operational Directorate comments
from Hannes Tschofenig, 06/11/2009.
Changes to this draft in comparison to the previous version (-07 vs.
-06):
1. deleted text and reference to ID.ietf-geopriv-policy (Thomson
2/26/09).
2. replaced text in Introduction referring to SIP (Thomson).
3. reworded section 3.4 on location URI authorization (Thomson).
Changes to this draft in comparison to the previous version (-06 vs.
-05):
1. replaced diagram (Thomson).
2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig).
3. redefined term, "Location-by-Reference" (Tschofenig).
4. redefined term, "Location Dereference Protocol" (Tschofenig).
5. reworded term, "Location URI" (Tschofenig).
6. modified steps, text, Figure 1 (Tschofenig).
7. deleted redundant text in paragraph, "Because a location URI..."
(Tschofenig).
8. modified Authorization model text paragraphs, (Tschofenig).
9. added qualifying sentence before sentence, "Thus, obfuscating the
location URI..." (Marshall based on question from Tschofenig).
10. replaced diagram with one that contains both "LIS - LS" labeling
(Martin).
11. added text to Introduction that a location URI is dynamic and may
change over time (Martin, 2/23/09).
12. section 3 text changed to make the makeup of a location URI less
stringent as to being guessable, etc. (Martin, 2/23/09).
13. reordered "C" requirements from those remaining: C8-->C7;
C9-->C8; C10-->C9.
14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5.
15. section-ized the overview, (section 3), for pointing to (Martin,
2/23/09)
16. edited section 3.4 to make clear that some default requirements
may be relaxed ONLY if explicit local policy exists. (RSM based on
Martin, 2/23/09).
17. added an citation for the geopriv-policy draft reference.
18. reworded first couple of paragraphs of Introduction for
readability.
Changes to this draft in comparison to the previous version (-05 vs.
-04):
1. Fixed minor spelilng errors.
Changes to this draft in comparison to the previous version (-04 vs.
-03):
1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08
list comments).
1. Relocated text in section 3 "Overview of Location-by-Reference"
to section 1 (Intro), (Thomson comments).
2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson
comments).
3. Fixed minor spelling errors, incl. Note B., Note C., etc., based
on (Thomson comments).
4. Added some qualifying text (security) around possession model,
based on (Thomson comments).
5. Replaced "use type" labels with "authorization models", "access
authorization model", and "possession authorization model", (Thomson
comments).
6. Changed the entity role of applying security from LIS (Server-
side authentication), to the Rule Maker (owner/Target) providing
policies to the LIS, (Thomson comments).
7. Changed requirement C3 to a MUST, (Thomson comments).
8. Added new requirement, C12, "C12. Location URI Lifetime:" as a
SHOULD for all, and MUST for possession auth model, (Thomson
comments).
9. Changed name of requirement C8 to "Location Only", (Thomson
comments).
10. Reworded C7 and D6 to be less implementation specific, (Thomson
comments).
11. Changed requirements C11, D11 to SHOULD, (Thomson comments).
12. (Section 5:) Removed lead in sentence for readibility, (Thomson
comments).
13. Remove "pawn ticket" reference - replaced with "possession
authorization model", (Thomson comments).
14. Added new paragraph to the security section (Thomson, 7/09/08
comments).
15. Corrected other minor spelling and wording errors and
deficiencies (refer to diff 04/03) (-Editor).
Changes to this draft in comparison to the previous version (-03 vs.
-02):
1. Changed wording of section 3 "Overview of Location-by-Reference"
(Polk, Thomson, Winterbottom ~ 4/1/08 list comments).
2. Added new requirement C4. "Location Information Masking:", based
on (Thomson ~4/1/08 list comment).
3. Added new requirement C11. "Location URI Use Type:", based on
(~4/1/08 list comments).
4. Added new requirement D11. "Location URI Use Type:", for deref.
based on (~4/1/08 list comments).
5. Replaced requirement D8. "Location URI Non-Anonymized" with
"Location Information Masking:".
Changes to this draft in comparison to the previous version (-02 vs.
-01):
1. Reworded Introduction (Barnes 12/6 list comments).
2. Changed name of "Basic Actors" section to "Overview of Location
by Reference" (Barnes).
3. Keeping the LCP term away (for now) since it is used as Link 7. References
Control Protocol elsewhere (IETF).
4. Changed formatting of Terminology section (Barnes). 7.1. Normative References
5. Requirement C2. changed to indicate that if the URI has a [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
lifetime, it has to have an expiry (Barnes) Requirement Levels", BCP 14, RFC 2119, March 1997.
6. C7. Changed title and wording based on suggested text and dhcp- 7.2. Informative References
uri-option example (Polk).
7. The new C2 req. describing valid-for, was also added into the [DHCP-LOC-URI] Polk, J., "Dynamic Host Configuration Protocol (DHCP)
deref section, as D6 IPv4 and IPv6 Option for a Location Uniform Resource
Identifier (URI)", Work in Progress, March 2010.
8. Changed C4 based on much list discussion - replaced by 3 new [HELD] Barnes, M., Winterbottom, J., Thomson, M., and B.
requirements... Stark, "HTTP Enabled Location Delivery (HELD)", Work
in Progress, August 2009.
9. Reworded C5 based on the follow-on C4 thread/discussion on list [LLDP-MED] Telecommunications Industry Association (TIA),
(~2/18). "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery", 2006.
10. Changed wording of D3 based on suggestion (Barnes). [LOC-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in the Session Initiation
Protocol (SIP)", Work in Progress, March 2010.
11. Reworded D4 per suggestion (Barnes). [LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Work in Progress,
February 2010.
12. Changed D5 based on comment (Barnes), and additional title and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J.,
text changes for clarity. and J. Polk, "Geopriv Requirements", RFC 3693,
February 2004.
13. Added D9 and D10 per Richard Barnes suggestions - something [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location
needed in addition to his own security doc. Object Format", RFC 4119, December 2005.
14. Deleted reference to individual Barnes-loc-sec draft per wg list [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
suggestion (Barnes), but need more text for this draft's security Location Configuration Protocol: Problem Statement and
section. Requirements", RFC 5687, March 2010.
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
Email: rmarshall@telecomsys.com EMail: rmarshall@telecomsys.com
URI: http://www.telecomsys.com URI: http://www.telecomsys.com
 End of changes. 103 change blocks. 
610 lines changed or deleted 322 lines changed or added

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