|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 9, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
|
|
|
|
|
|
| The charter of the GEOPRIV working group
is reported below.
|
|
|
|
As more and more resources become available on the Internet, some
applications need to acquire geographic location information about
certain resources or entities. These applications include navigation,
emergency services, management of equipment in the field, and other
location-based services.
But while the formatting and transfer of such information is in some
sense a straightforward process, the implications of doing it,
especially in regards to privacy and security, are anything but.
The primary task of the Geographic Location/Privacy (GEOPRIV)
working group will be to assess the the
authorization, integrity and privacy requirements that must be met in
order to transfer such information, or authorize the release or
representation of such information through an agent.
In addition, the working group will select an already standardized
format to recommend for use in representing location per se. A key
task will be to enhance this format and protocol approaches using the
enhanced format, to ensure that the security and privacy methods are
available to diverse location-aware applications. Approaches to be
considered will include (among others) data formats incorporating
fields directing the privacy handling of the location information and
possible methods of specifying variable precision of location.
Also to be considered will be: authorization of requestors and
responders; authorization of proxies (for instance, the ability to
authorize a carrier to reveal what timezone one is in, but not what
city. An approach to the taxonomy of requestors, as well as to the
resolution or precision of information given them, will be part of this
deliverable.
The combination of these elements should provide a service capable of
transferring geographic location information in a private and secure
fashion (including the option of denying transfer).
For reasons of both future interoperability and assurance of the
security and privacy goals, it is a goal of the working group to
deliver a specification that has broad applicablity and will become
mandatory to implement for IETF protocols that are location-aware.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
geopriv-http-
location-
delivery-07
Waiting for
AD Go-Ahead
Apr 17, 2008
(43 p.)
[pdf(2)]
[html]
|
M. Barnes |
|
HTTP Enabled Location Delivery (HELD) |
|
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
geopriv-pdif-
lo-profile-11
AD Evaluation
Feb 20, 2008
(34 p.)
[pdf(2)]
[html]
|
J. Winterbottom
M. Thomson
H. Tschofenig |
| GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations |
|
The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise
when information needs to be constrained in how it is represented.
In these circumstances the range of options that need to be
implemented are reduced. There is growing interest in being able to
use location information contained in a PIDF-LO for routing
applications. To allow successful interoperability between
applications, location information needs to be normative and more
tightly constrained than is currently specified in the RFC 4119
(PIDF-LO). This document makes recommendations on how to constrain,
represent and interpret locations in a PIDF-LO. It further
recommends a subset of GML that is mandatory to implement by
applications involved in location based routing.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
geopriv-radius-lo-19
Waiting for
AD Go-Ahead
Jan 31, 2008
(63 p.)
[pdf(2)]
[html]
|
H. Tschofenig
F. Adrangi
M. Jones
A. Lior
B. Aboba |
|
Carrying Location Objects in RADIUS and Diameter |
|
This document describes procedures for conveying access network
ownership and location information based on a civic and geospatial
location format in Remote Authentication Dial In User Service
(RADIUS) and Diameter.
The distribution of location information is a privacy sensitive task.
Dealing with mechanisms to preserve the user's privacy is important
and addressed in this document.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
geopriv-l7-lcp-ps-07
ID Exists
Mar 29, 2008
(25 p.)
[pdf(2)]
[html]
|
H. Tschofenig
H. Schulzrinne |
|
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements |
|
This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location
Information Server (LIS) that is located in the access network. The
obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as
input to the Location-to-Service Translation Protocol (LoST) or to
convey location within SIP to other entities.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
geopriv-
lis-discovery-00
ID Exists
Dec 11, 2007
(23 p.)
[pdf(2)]
[html]
|
M. Thomson
J. Winterbottom |
|
Discovering the Local Location Information Server (LIS) |
|
A method is described for the discovery of a Location Information
Server. The method consists of attempting to use a Dynamic Host
Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR
(U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP.
This document also defines a U-NAPTR Application Service for a LIS,
with a specific Application Protocol for the HTTP Enabled Location
Delivery (HELD) protocol.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## GEOPRIVwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
barnes-geopriv-
lo-sec-02
ID Exists
Feb 25, 2008
(29 p.)
[pdf(2)]
[html]
|
R. Barnes
M. Lepinski
H. Tschofenig
H. Schulzrinne |
|
Security Requirements for the Geopriv Location System |
|
Internet protocols that deal with presence-based location objects
support a wide variety of applications. However, the dissemination
of location objects from sources of location to consumers is a common
feature of all location-based applications. In order to enable the
development of broadly-applicable security and privacy mechanisms for
dissemination of location objects, this document describes an end-to-end
architecture for policy-constrained location distribution. In
this architecture, location distribution is accomplished by a set of
distributed actors. We describe the assurances that these actors
require from the architecture, and derive more a more detailed
description of the security features required to provide those
assurances.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
busin-geopriv-
location-qos-req-01
ID Exists
Nov 19, 2007
(11 p.)
[pdf(2)]
[html]
|
A. Busin
Y. Jin
M. Mosmondor
S. Loreto |
|
Requirements for a Location Quality of Service (QoS) Information Object |
|
This document describes requirements for Location Quality of Service
(QoS) Information that may be carried both in the Geopriv Layer 7
Location Configuration Protocol (L7 LPC) and in the Location
Dereference Protocol (LDP) requests. The Location QoS Information is
used for expressing the required or desired level of quality,
accuracy, response time, and age of requested Location Information.
The resulting Location Information is conveyed in existing location
formats wrapped in GEOPRIV privacy extensions to the Presence
Information Document Format (PIDF-LO) [RFC4119].
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mahy-geopriv-
sip-loc-pkg-02
ID Exists
(Recently Expired)
Jul 8, 2007
(9 p.)
[pdf(2)]
[html]
|
R. Mahy |
|
A Location Dereference Event Package using SIP |
|
This document describes a Session Initiation Protocol (SIP) event
package to dereference raw location data about named SIP resources
(as opposed to presence data with embedded filtered location) as a
GEOPRIV Using Protocol. The resulting location information is
conveyed in existing location formats wrapped in GEOPRIV privacy
extensions to the Presence Information Document Format (PIDF-LO). In
the envisioned usage, location disclosure is limited to voluntary
disclosure to the target of its own location or to a trusted service
(such as a presence server) which enforces the target's privacy rules
on the target's behalf.
|
|
|
|
|
|
|
|
|
|
|
| | |
peterson-geopriv-
retransmission-00
ID Exists
Feb 15, 2008
(12 p.)
[pdf(2)]
[html]
|
J. Peterson
T. Hardie
J. Morris |
|
Implications of for SIP Location Conveyance |
|
This document explores an ambiguity in the interpretation of the
<retransmission-allowed> element of the Presence Information Data
Format for Location Objects (PIDF-LO) in cases where PIDF-LO is
conveyed by the Session Initiation Protocol (SIP). It provides
recommendations for how the SIP location conveyance mechanism should
adapt to these ambiguities.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
schulzrinne-geopriv-
relo-03
ID Exists
Mar 4, 2007
(13 p.)
[pdf(2)]
[html]
|
H. Schulzrinne |
|
RELO: Retrieving End System Location Information |
In some network configurations, it is desirable for the end system to
be able to obtain its geodetic or civic location using an
application-layer protocol. This document describes RELO (Retrieving
End system LOcation), a simple, HTTP-based stateless protocol profile
that fulfills this need.
This specification requests the registration of a new MIME type:
application/relo+xml.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
thomson-geopriv-
held-
measurements-02
ID Exists
May 8, 2008
(48 p.)
[pdf(2)]
[html]
|
M. Thomson
J. Winterbottom |
|
Using Device-provided Location-Related Measurements in HELD |
|
A method is described by which a Device is able to provide location-related
measurement data to a LIS within a HELD request. Location-related
measurement information are observations concerning
properties related to the position of a Device, which could be data
about network attachment or about the physical environment around the
LIS. When a LIS generates location information for a device,
information from the device can improve the accuracy of the location
estimate. A basic set of location-related measurements are defined,
including common modes of network attachment as well as assisted
Global Navigation Satellite System (GNSS) parameters.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
thomson-geopriv-
location-quality-00
ID Exists
Dec 21, 2007
(18 p.)
[pdf(2)]
[html]
|
M. Thomson
J. Winterbottom |
|
Specifying Location Quality Constraints in Location Protocols |
|
Location determination methods produce results of varying quality.
In general, the quality of location information increases as the
effort expended in generating the information increases. This
document provides XML extension objects that can be added to any
protocol that provides location information. These elements provide
the ability to communicate location quality constraints to the
location server.
This document provides semantics, examples and security
considerations for the HELD protocol.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
thomson-geopriv-
uncertainty-00
ID Exists
Nov 12, 2007
(38 p.)
[pdf(2)]
[html]
|
M. Thomson
J. Winterbottom |
|
Representation of Uncertainty and Confidence in PIDF-LO |
|
The key concepts of uncertainty and confidence as they pertain to
location information are defined. A form for the representation of
confidence in Presence Information Data Format - Location Object
(PIDF-LO) is described, optionally including the form of the
uncertainty. Suggested methods for the manipulation of location
estimates that include uncertainty information are outlined.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
tschofenig-geopriv-
dhcp-circle-00
ID Exists
Feb 18, 2008
(15 p.)
[pdf(2)]
[html]
|
H. Tschofenig
J. Winterbottom |
|
Specifying a Circular Uncertainty Area Using DHCP |
This document specifies how a circular area representing the location
of device can be returned using DHCP. The document also shows how
the data returned from DHCP can be encoded into GML for using in a
PIDF-LO in an unambiguous or contentious manner.
This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed
issues.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
tschofenig-geopriv-
http-using-
protocol-00
ID Exists
(Recently Expired)
Jul 2, 2007
(23 p.)
[pdf(2)]
[html]
|
H. Tschofenig
H. Schulzrinne |
|
A GEOPRIV HTTPS Using Protocol |
|
This document describes an approach to to use Hypertext Transfer
Protocol (HTTP) over Transport Layer Protocol (TLS) to transport
Presence Information Data Format Location Objects (PIDF-LO) (see
RFC 4119).
It is a GEOPRIV using protocol as described in Section 5.2 or
RFC 3693 to resolve an identifier, which denotes a reference, to a
PIDF-LO. The document assumes that the HTTP client possesses the
reference that is obtained using a mechanism that are outside the
scope of this document and conveys it to the HTTP server in order to
retrieve a PIDF-LO in a response.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
winterbottom-
geopriv-
deref-protocol-00
ID Exists
Nov 11, 2007
(28 p.)
[pdf(2)]
[html]
|
J. Winterbottom
H. Tschofenig
H. Schulzrinne
M. Thomson
M. Dawson |
|
An HTTPS Location Dereferencing Protocol Using HELD |
|
This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference into a Presence Information Data
Format Location Object (PIDF-LO). The document assumes that a
Location Recipient possesses a secure HELD URI that can be used in
conjunction with the HELD protocol to request the location of the
Target.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
winterbottom-
geopriv-
held-context-02
ID Exists
Feb 20, 2008
(28 p.)
[pdf(2)]
[html]
|
J. Winterbottom
H. Tschofenig
M. Thomson |
|
HELD Protocol Context Management Extensions |
|
This document describes a protocol extension for the HTTP Enabled
Location Delivery (HELD) protocol. It allows a Target to manage
their location information on a Location Information Server (LIS)
through the application of constraints invoked by accessing a
location URI. Constraints described in this memo restrict how often
location can be accessed through a location URI, how long the URI is
valid for, and the type of location information returned when a
location URI is accessed. Extension points are also provided.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
winterbottom-
geopriv-
held-identity-
extensions-04
ID Exists
Nov 19, 2007
(17 p.)
[pdf(2)]
[html]
|
J. Winterbottom
M. Thomson
H. Tschofenig |
|
HELD Identity Extensions |
When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of arriving message as a pointer to the location
determination process. This is appropriate in many environments.
However, when an entity acting on behalf of the Target would like to
request location information then the source IP address of the
request will lead to wrong results. In other cases the IP address is
not the only identifier that serves as an input to the location
determination procedure.
This document extends the HELD protocol to allow the location request
message to carry additional identifiers assisting the location
determination process. It defines a set of URIs for Target
identifiers and an XML containment schema. As such, this extension
is used in conjunction with HELD to provide Target identification.
Examples and usage in HELD message syntax are provided.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
