GEOPRIV H. Schulzrinne, Ed.
Internet-Draft Columbia U.
Intended status: Standards Track H. Tschofenig, Ed.
Expires: July 9, 2007 Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
Cisco
January 5, 2007
Geolocation Policy: A Document Format for Expressing Privacy Preferences
for Location Information
draft-ietf-geopriv-policy-10.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Schulzrinne, et al. Expires July 9, 2007 [Page 1]
Internet-Draft Geolocation Policy January 2007
Abstract
This document defines an authorization policy language for controling
access to location information. It extends the Common Policy
authorization framework to provide location-specific access control.
More specifically, this document defines condition elements specific
to location information that allow to restrict access based on the
current location of the Target. Furthermore, it offers location-
specific transformation elements to reduce the granularity of the
returned location information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Basic Data Model and Processing . . . . . . . . . . . . . 8
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8
4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9
4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9
4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12
6.2. Set Retention-Expires . . . . . . . . . . . . . . . . . . 12
6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13
6.5. Provide Location Information . . . . . . . . . . . . . . . 13
6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 13
6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 14
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Rule Example with Civic Location Condition . . . . . . . . 16
7.2. Rule Example with Geodetic Location Condition . . . . . . 17
7.3. Rule Example with Civic and Geodetic Location Condition . 18
7.4. Rule Example with Location-based Transformations . . . . . 19
8. XML Schema for Location Profiles . . . . . . . . . . . . . . . 21
9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Geolocation Policy Schema Registration . . . . . . . . . . 24
10.2. Geolocation Policy Namespace Registration . . . . . . . . 24
10.3. Geolocation Policy Location Profile Registry . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Schulzrinne, et al. Expires July 9, 2007 [Page 2]
Internet-Draft Geolocation Policy January 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Schulzrinne, et al. Expires July 9, 2007 [Page 3]
Internet-Draft Geolocation Policy January 2007
1. Introduction
Location information needs to be protected against unauthorized
access to preserve the privacy of humans. In RFC 3693 [1], a
protocol-independent model for access to geographic information is
defined. The model includes a Location Generator (LG) that
determines location information, a Location Server (LS) that
authorizes access to location information, a Location Recipient (LR)
that requests and receives location information, and a Rule Maker
(RM) that writes authorization policies. An authorization policy is
a set of rules that regulates an entity's activities with respect to
privacy-sensitive information, such as location information.
The data object containing location information in the context of
this document is referred to as a Location Object (LO). The basic
rule set defined in the Presence Information Data Format Location
Object (PIDF-LO) [2] can restrict how long the Location Recipient is
allowed to retain the information, and it can prohibit further
distribution. It also contains a reference to an enhanced rule set
and a human readable privacy policy. The basic rule set, however,
does not allow to control access to location information based on
specific Location Recipients. This document describes an enhanced
rule set that provides richer constraints on the distribution of LOs.
The rule set allows the entity that uses the rules defined in this
document to restrict the retention and to enforce access restrictions
on location data, including prohibiting any dissemination to
particular individuals, during particular times or when the Target is
located in a specific region. The RM can also stipulate that only
certain parts of the Location Object are to be distributed to
recipients or that the resolution of parts of the Location Object is
reduced.
The typical sequence of operations is as follows. A Location Server
receives a query for location information for a particular Target,
via the using protocol [1]. The using protocol provides the identity
of the requestor, either at the time of the query or when subscribing
to the location information. The authenticated identity of the
Location Recipient, together with other information provided by the
using protocol or generally available to the server, is then used for
searching through the rule set. If more than one rule matches the
condition element, then the combined permission is evaluated
according to the description in Section 10 of [3]. The result of the
rule evalation is applied to the location information, yielding a
possibly modified Location Object that is delivered to the Location
Recipient.
This document does not describe or mandate
Schulzrinne, et al. Expires July 9, 2007 [Page 4]
Internet-Draft Geolocation Policy January 2007
o the protocol used to convey location information from the Location
Server to the Location Recipient (i.e., the using protocol; see
RFC 3693 [1]),
o the protocol to update authorization policies defined in this
document (although the usage of XCAP [10] is suggested),
o the protocol used between the Location Generator and the Location
Server to deliver location information.
This document extends the Common Policy framework defined in [3].
That document provides an abstract framework for expressing
authorization policy rules. As specified there, each such rule
consists of conditions, actions and transformations. Conditions
determine under which circumstances the entity executing the rules,
for example a Location Server, is permitted to apply actions and
transformations. Transformations regulate in a location information
context how a Location Server handles Location Objects; it might
limit when and how data and the authorization policy can be
distributed and may modify the information elements that are returned
to the requestor, for example, by reducing the granularity of
returned location information.
The XML schema defined in Section 9 extends the Common Policy schema
by introducing new child elements to the condition and transformation
elements. This document does not define child elements for the
action part of a rule.
Schulzrinne, et al. Expires July 9, 2007 [Page 5]
Internet-Draft Geolocation Policy January 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
This document reuses the terminology of RFC 3693 [1], such as
Location Server (LS), Location Recipient (LR), Rule Maker (RM),
Target, Location Generator (LG) and Location Object (LO). This
document and the common policy document [3] share the following
terminology:
Presentity or Target:
RFC 3693 [1] uses the term Target to identify the object or person
of which location information is required. The presence model
described in RFC 2778 [11] uses the term presentity to describe
the entity that provides presence information to a presence
service. A Presentity in a presence system is a Target in a
location information system.
Watcher or Location Recipient:
The receiver of location information is the Location Recipient
(LR) in the terminology of RFC 3693 [1]. A watcher in a presence
system, i.e., an entity that requests presence information about a
presentity, is a Location Recipient in a location information
system.
Authorization policy:
An authorization policy is given by a rule set. A rule set
contains an unordered list of rules. Each rule has a condition,
an action and a transformation component.
Permission:
The term permission refers to the action and transformation
components of a rule.
The terms 'authorization policy', 'policy' and 'rule set' are used
interchangeable. The terms 'authorization policy rule', 'policy
rule' and 'rule' are used interchangeable.
The term 'using protocol' is defined in [1] and refers to the
Schulzrinne, et al. Expires July 9, 2007 [Page 6]
Internet-Draft Geolocation Policy January 2007
protocol that is used to request access to and to return privacy
sensitive data items.
Note that this document often points to Location Servers as the
entities that evaluate the authorization policies described in this
document. The geolocation privacy architecture is, as motivated in
RFC 4079 [12], aligned with the presence architecture and a Presence
Server is an entity that distributes location information along with
other presence-specific XML data elements.
Schulzrinne, et al. Expires July 9, 2007 [Page 7]
Internet-Draft Geolocation Policy January 2007
3. Generic Processing
3.1. Basic Data Model and Processing
Since this document extents the Common Policy framework defined in
[3], it also inherits its basic data model and processing.
3.2. Rule Transport
There are two ways how the authorization rules described in this
document may be conveyed between different parties:
o RFC 4119 [2] allows enhanced authorization policies to be
referenced via a Uniform Resource Locator (URL) in the 'ruleset-
reference' element. The ruleset-reference' element is part of the
basic rules that always travel with the Location Object.
o Authorization policies might, for example, also be stored at a
Location Server / Presence Server. The Rule Maker therefore needs
to use a protocol to create, modify and delete the authorization
policies defined in this document. Such a protocol is available
with the Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) [10].
Schulzrinne, et al. Expires July 9, 2007 [Page 8]
Internet-Draft Geolocation Policy January 2007
4. Location-specific Conditions
This section describes the location-specific conditions of a rule,
namely the civic and geodetic location conditions. The <conditions>
element MAY contain zero, one or an unbounded number of <location-
condition> child element(s). Providing more than one <location-
condition> child element may not be useful since all child elements
of the <conditions> element must evaluate to TRUE in order for the
<conditions> element to be TRUE. The <location-condition> element
MUST contain at least one <location> child element. The <location-
condition> element evaluates to TRUE if any of its child elements is
TRUE, i.e., a logical OR. A location profile needs to describe under
what conditions each <location> element evaluates to TRUE. This
document defines two location profiles, one civic and one geodetic
location profile.
The <location-condition> and the <location> elements provide
extension points. If an extension is not understood by the entity
evaluating the rules then the rule evaluates to FALSE.
4.1. Geodetic Location Condition Profile
The geodetic location profile is identified by the token 'geodetic-
condition'. Rule Makers use this profile by placing a GML [5]
<Polygon> element within the <location> element.
The <location> element containing the information for the geodetic
location profile evaluates to TRUE if the current location of the
Target is within the described Polygon. This might require a point-
in-polygon, polygon-in-polygon, or a similar computation. If the
geodetic location of the Target is unknown then the <location>
element containing the information for the geodetic location profile
evaluates to FALSE.
The polygon that uses the "gml:Polygon" element is specified by a
sequence of points. A polygon requires at least four points, where
the first and last point MUST be the same.
Points specified in a polygon MUST be coplanar. However,
implementations SHOULD be prepared to accept small variations that
might occur depending on whether the the polygon is specified on a
plane in space, or only relative to the ellipsoid. To avoid
implementation complexity, implementations MAY choose to not support
polygons that include varying altitude. Therefore, two polygon forms
are permitted: polygons specified using EPSG 4326, and polygons
specified using EPSG 4979 with a constant altitude value.
Interpolation between points is linear, as defined for the "gml:
Schulzrinne, et al. Expires July 9, 2007 [Page 9]
Internet-Draft Geolocation Policy January 2007
LinearRing" element. Implementations SHOULD minimize this
interpolation error by ensuring that the sides of polygons are as
short as possible.
Implementations are REQUIRED to support the following coordinate
reference systems based on WGS 84 [6]. These are identified using
the European Petroleum Survey Group (EPSG) Geodetic Parameter
Dataset, as formalized by the Open Geospatial Consortium (OGC):
2D:
WGS 84 (latitude, longitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.
3D:
WGS 84 (latitude, longitude, altitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS.
The most recent version of the EPSG Geodetic Parameter Dataset SHOULD
be used. A CRS MUST be specified using the above URN notation only,
implementations do not need to support user-defined CRSs.
Implementations MUST specify the CRS using the "srsName" attribute on
the outermost geometry element. The CRS MUST NOT be changed for any
sub-elements. The "srsDimension" attribute MUST be omitted, since
the number of dimensions in these CRSs is known.
4.2. Civic Location Condition Profile
The civic location profile is identified by the token 'civic-
condition'. Rule Makers use this profile by placing a <civicAddress>
element, defined in [7], within the <location> element.
All child elements of <location> element that carry civicAddress
elements MUST evaluate to TRUE (i.e., logical AND) in order for the
<location> element to evaluate to TRUE. For each element value a
string-by-string comparison is performed.
The <location> element containing information of the civic location
profile evaluates to TRUE if all child elements evaluate to TRUE
(i.e., a logical AND). If the civic location of the Target is
unknown, then the <location> element containing the information for
the civic location profile evaluates to FALSE. This case may occur,
for example, if location information has been removed by earlier
transmitters of location information or if only the geodetic location
is known.
Schulzrinne, et al. Expires July 9, 2007 [Page 10]
Internet-Draft Geolocation Policy January 2007
5. Actions
This document does not define location-specific actions.
Schulzrinne, et al. Expires July 9, 2007 [Page 11]
Internet-Draft Geolocation Policy January 2007
6. Transformations
This document defines several elements that allow Rule Makers to
specify transformations that
o reduce the accuracy of the returned location information, and
o set the basic authorization policies carried inside the PIDF-LO.
6.1. Set Retransmission-Allowed
This element asks the LS to change or set the value of the
<retransmission-allowed> element in the PIDF-LO. The data type of
the <set-retransmission-allowed> element is a boolean.
If the value of the <set-retransmission-allowed> element is set to
TRUE then the <retransmission-allowed> element in the PIDF-LO MUST be
set to TRUE. If the value of the <set-retransmission-allowed>
element is set to FALSE, then the <retransmission-allowed> element in
the PIDF-LO MUST to be set to FALSE.
If the <set-retransmission-allowed> element is absent then the value
of the <retransmission-allowed> element in the PIDF-LO MUST be kept
unchanged or, if the PIDF-LO is created for the first time, then the
value MUST be set to FALSE.
6.2. Set Retention-Expires
This transformation asks the LS to change or set the value of the
<retention-expires> element in the PIDF-LO. The data type of the
<set-retention-expires> element is an integer.
The value provided with the <set-retention-expires> element indicates
seconds and these seconds are added to the current date.
If the <set-retention-expires> element is absent then the value of
the <retention-expires> element in the PIDF-LO is kept unchanged or,
if the PIDF-LO is created for the first time, then the value MUST be
set to 0, i.e., immediate expiry.
6.3. Set Note-Well
This transformation asks the LS to change or set the value of the
<note-well> element in the PIDF-LO. The data type of the <set-note-
well> element is a string.
The value provided with the <set-note-well> element contains a
privacy statement as a human readable text string and an 'xml:lang'
Schulzrinne, et al. Expires July 9, 2007 [Page 12]
Internet-Draft Geolocation Policy January 2007
attribute denotes the language of the human readable text.
If the <set-note-well> element is absent, then the value of the
<note-well> element in the PIDF-LO is kept unchanged or, if the
PIDF-LO is created for the first time, then no content is provided
for the note-well element.
6.4. Keep Ruleset Reference
This transformation allows to influence whether the <ruleset-
reference> element in the PIDF-LO carries the extended authorization
rules defined in [3]. The data type of the <keep-rule-reference>
element is Boolean.
If the value of the <keep-rule-reference> element is set to TRUE,
then the the <ruleset-reference> element in the PIDF-LO is set to
TRUE. If the value of the <keep-rule-reference> element is set to
FALSE, then the <ruleset-reference> element in the PIDF-LO MUST NOT
contain a reference. The reference to the ruleset is removed and no
rules are carried as MIME bodies (in case of CID URIs).
If the <keep-rule-reference> element is absent, then the value of the
<ruleset-reference> element in the PIDF-LO is kept unchanged or, if
the PIDF-LO is created for the first time then the <ruleset-
reference> element MUST NOT contain a reference.
6.5. Provide Location Information
The <provide-location> element contains child elements of a specific
location profile that controls the granularity of returned location
information. This document defines two location profiles that appear
as <provide-civic> and <provide-geo> child elements of the <provide-
location> element. The <provide-location> element MAY contain a
<provide-civic> and/or a <provide-geo> child element to control the
granularity of location information being made available. If the
<provide-location> element has a <provide-civic> child element then
civic location information is disclosed as described in
Section 6.5.1, subject to availability. If the <provide-location>
element has a <provide-geo> child element then geodetic location
information is disclosed as described in Section 6.5.2, subject to
availability. If the <provide-location> element has no child
elements then civic as well as geodetic location information is
disclosed without reducing its granularity, subject to availability.
6.5.1. Civic Location Profile
This profile uses the token 'civic-transformation'. This profile
allows civic location transformations to be specified by means of the
Schulzrinne, et al. Expires July 9, 2007 [Page 13]
Internet-Draft Geolocation Policy January 2007
<provide-civic> element that restricts the level of civic location
information the LS is permitted to disclose. The symbols of these
levels are: 'country', 'region', 'city', 'building', 'full'. Each
level is given by a set of civic location data items such as
<country> and <A1>, ..., <POM>, as defined in [7]. Each level
includes all elements included by the lower levels.
The 'country' level includes only the <country> element; the 'region'
level adds the <A1> element; the 'city' level adds the <A2> and <A3>
elements; the 'building' level and the 'full' level add further civic
location data as shown below:
full
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>, <ZIP>
<BLD>,<UNIT>,<ROOM>,<PLC>, <PCN>, <POBOX>, <ADDCODE>, <SEAT>
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
building
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>
<POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>, <ZIP>,
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
city
{<country>, <A1>, <A2>}
|
|
region
{<country>, <A1>}
|
|
country
{<country>}
|
|
{ }
The schema of the <provide-civic> element is defined in Section 8.
6.5.2. Geodetic Location Profile
This profile uses the token 'geodetic-transformation'. This profile
allows geodetic location transformations to be specified by means of
the <provide-geo> element that restrict the resolution of geodetic
location information based on the value provided in the <latitude-
Schulzrinne, et al. Expires July 9, 2007 [Page 14]
Internet-Draft Geolocation Policy January 2007
resolution>, <longitude-resolution> and <altitude-resolution> child
elements of the <provide-geo> element. The resolution is specified
as a positive, non-zero number r. If n is the nominal coordinate
value (longitude or latitude), the rounded value is computed as
floor(n/r + 0.5) * r.
For example, if the latitude is n=38.89868 and r=0.01, the latitude
value rendered for the Location Recipient is 38.90. If the longitude
is n=77.03723 and r=0.01, the longitude is rendered as 77.04. This
computation also works for values of r that are not integer powers of
10 or r > 1. For example, to round longitude to timezone accuracy,
one would use r=15 and obtain a value of 75 in this example.
If no <latitude-resolution> (respectively <longitude-resolution> and
<altitude-resolution>) child element is provided then the latitude
(respectively longitude and altitude) value is provided in the
available accuracy.
The schema of the <provide-geo> element is defined in Section 8.
Schulzrinne, et al. Expires July 9, 2007 [Page 15]
Internet-Draft Geolocation Policy January 2007
7. Examples
This section provides three examples for authorization policy rules
using the extensions defined in this document.
7.1. Rule Example with Civic Location Condition
This example illustrates a single rule that employs the civic
location condition that matches if the current location of the Target
matches the content of the child elements of the <location> element.
Requests match only if the Target is at a civic location with country
set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to
'Munich', city division (A4) set to 'Perlach', street name (A6) set
to 'Otto-Hahn-Ring' and house number (HNO) set to '6'.
No actions and transformation child elements are provided in this
rule example. The actions and transformation could include presence
specific information when the Geolocation Policy framework is applied
to the Presence Policy framework (see [13]).
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location profile="civic-condition"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
Schulzrinne, et al. Expires July 9, 2007 [Page 16]
Internet-Draft Geolocation Policy January 2007
7.2. Rule Example with Geodetic Location Condition
This example illustrates a rule that employs the geodetic location
condition. The rule matches if the current location of the Target is
inside the area specified by the polygon. The polygon uses the EPSG
4326 coordinate reference system. No altitude is included in this
example, indicating that altitude is unknown.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="BB56A19">
<conditions>
<gp:location-condition>
<gp:location profile="geodetic-condition">
<gml:Polygon
srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:pos>42.556844 -73.248157</gml:pos>
<gml:pos>42.549631 -73.237283</gml:pos>
<gml:pos>42.539087 -73.240328</gml:pos>
<gml:pos>42.535756 -73.254242</gml:pos>
<gml:pos>42.542969 -73.265115</gml:pos>
<gml:pos>42.553513 -73.262075</gml:pos>
<gml:pos>42.556844 -73.248157</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location>
</gp:location-condition>
</conditions>
<transformations/>
</rule>
</ruleset>
The following alternative example shows the same polygon with a
constant altitude included that is specified using EPSG 4979 and the
"gml:posList" element. The "gml:posList" element is interpreted as a
list with the dimension of the CRS indicating how many values are
required for each point.
Schulzrinne, et al. Expires July 9, 2007 [Page 17]
Internet-Draft Geolocation Policy January 2007
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="BB56A19">
<conditions>
<gp:location-condition>
<gp:location profile="geodetic-condition">
<gml:Polygon
srsName="urn:ogc:def::crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
42.556844 -73.248157 36.6
42.549631 -73.237283 36.6
42.539087 -73.240328 36.6
42.535756 -73.254242 36.6
42.542969 -73.265115 36.6
42.553513 -73.262075 36.6
42.556844 -73.248157 36.6
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
7.3. Rule Example with Civic and Geodetic Location Condition
This example illustrates a rule that employs a mixed civic and
geodetic location condition. Depending on the available type of
location information, namely civic or geodetic location information,
one of the location elements may match.
Schulzrinne, et al. Expires July 9, 2007 [Page 18]
Internet-Draft Geolocation Policy January 2007
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location profile="civic-condition"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
<gp:location profile="geodetic-condition">
<gml:Polygon
srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:pos>42.556844 -73.248157</gml:pos>
<gml:pos>42.549631 -73.237283</gml:pos>
<gml:pos>42.539087 -73.240328</gml:pos>
<gml:pos>42.535756 -73.254242</gml:pos>
<gml:pos>42.542969 -73.265115</gml:pos>
<gml:pos>42.553513 -73.262075</gml:pos>
<gml:pos>42.556844 -73.248157</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
7.4. Rule Example with Location-based Transformations
This example shows the transformations specified in this document.
The <provide-civic> element indicates that the available civic
location information is reduced to building level granularity. If
geodetic location information is requested then a granularity
reduction is provided as well.
Schulzrinne, et al. Expires July 9, 2007 [Page 19]
Internet-Draft Geolocation Policy January 2007
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:lp="urn:ietf:params:xml:ns:geopriv-location-profiles">
<rule id="AA56i09">
<conditions/>
<actions/>
<transformations>
<gp:set-retransmission-allowed>false
</gp:set-retransmission-allowed>
<gp:set-retention-expires>86400</gp:set-retention-expires>
<gp:set-note-well xml:lang="en">Don't distribute by location.
</gp:set-note-well>
<gp:keep-rule-reference>false
</gp:keep-rule-reference>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>building
</lp:provide-civic>
</gp:provide-location>
<gp:provide-location
profile="geodetic-transformation">
<lp:provide-geo>
<lp:latitude-resolution>0.01
</lp:latitude-resolution>
<lp:longitude-resolution>0.01
</lp:longitude-resolution>
<lp:altitude-resolution>0.01
</lp:altitude-resolution>
</lp:provide-geo>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
Schulzrinne, et al. Expires July 9, 2007 [Page 20]
Internet-Draft Geolocation Policy January 2007
8. XML Schema for Location Profiles
This section defines the location profiles used as child elements of
the transformation element.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv-location-profiles"
xmlns:lp="urn:ietf:params:xml:ns:geopriv-location-profiles"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- profile="civic-transformation" -->
<xs:element name="provide-civic">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="building"/>
<xs:enumeration value="city"/>
<xs:enumeration value="region"/>
<xs:enumeration value="country"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- profile="geodetic-transformation" -->
<xs:element name="provide-geo">
<xs:complexType>
<xs:sequence>
<xs:element name="latitude-resolution"
type="xs:double" minOccurs="0" maxOccurs="1"/>
<xs:element name="longitude-resolution"
type="xs:double" minOccurs="0" maxOccurs="1"/>
<xs:element name="altitude-resolution"
type="xs:double" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Schulzrinne, et al. Expires July 9, 2007 [Page 21]
Internet-Draft Geolocation Policy January 2007
9. XML Schema
This section presents the XML schema that defines the Geolocation
Policy schema described in this document. The Geolocation Policy
schema extends the Common Policy schema (see [3]) by introducing new
members of the 'condition' and 'transformation' substitution groups
whose heads (namely the elements <condition> and <transformation>).
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Geopriv Conditions -->
<xs:element name="location-condition"
type="gp:locationconditionType"/>
<xs:complexType name="locationconditionType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="location" type="gp:locationType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="locationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
Schulzrinne, et al. Expires July 9, 2007 [Page 22]
Internet-Draft Geolocation Policy January 2007
</xs:complexType>
<!-- Geopriv transformations -->
<xs:element name="set-retransmission-allowed"
type="xs:boolean" default="false"/>
<xs:element name="set-retention-expires"
type="xs:integer" default="0"/>
<xs:element name="set-note-well"
type="gp:notewellType"/>
<xs:element name="keep-rule-reference"
type="xs:boolean" default="false"/>
<xs:element name="provide-location"
type="gp:providelocationType"/>
<xs:complexType name="notewellType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="providelocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Schulzrinne, et al. Expires July 9, 2007 [Page 23]
Internet-Draft Geolocation Policy January 2007
10. IANA Considerations
There are several IANA considerations associated with this
specification.
10.1. Geolocation Policy Schema Registration
URI: urn:ietf:params:xml:schema:geolocation-policy
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@siemens.com).
XML: The XML schema to be registered is contained in Section 9. Its
first line is
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
</xs:schema>
10.2. Geolocation Policy Namespace Registration
URI: urn:ietf:params:xml:ns:geolocation-policy
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@siemens.com).
XML:
Schulzrinne, et al. Expires July 9, 2007 [Page 24]
Internet-Draft Geolocation Policy January 2007
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Geolocation Policy Namespace</title>
</head>
<body>
<h1>Namespace for Geolocation Authorization Policies</h1>
<h2>urn:ietf:params:xml:schema:geolocation-policy</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
10.3. Geolocation Policy Location Profile Registry
This document seeks to create a registry of location profile names
for the Geolocation Policy framework. Profile names are XML tokens.
This registry will operate in accordance with RFC 2434 [8], Standards
Action.
This document defines the following profile names:
geodetic-condition: Defined in Section 4.1.
civic-condition: Defined in Section 4.2.
geodetic-transformation: Defined in Section 6.5.2.
civic-transformation: Defined in Section 6.5.1.
Schulzrinne, et al. Expires July 9, 2007 [Page 25]
Internet-Draft Geolocation Policy January 2007
11. Security Considerations
This document aims to make it simple for users to prevent the
unintended disclosure of private information to third parties.
Security threats are described in [9] and are applicable to this
draft as well. Security requirements are addressed in [1]. Aspects
of combining permissions in cases of multiple occurrence are treated
in [3]). How the behavior of Location Servers can be regulated in
terms of Location Object handling in a privacy-safe fashion is
specified in Section 6.
Schulzrinne, et al. Expires July 9, 2007 [Page 26]
Internet-Draft Geolocation Policy January 2007
12. References
12.1. Normative References
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[3] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[5] OpenGIS, "OpenGIS Geography Markup Language (GML)
Implementation Specification, Version 3.00, OGC 02 023r4",
http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003.
[6] OpenGIS, "US National Imagery and Mapping Agency, "Department
of Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition, NIMA TR8350.2", , January 2000.
[7] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in
progress), September 2006.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[9] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
12.2. Informative References
[10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12 (work in progress), October 2006.
[11] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[12] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", RFC 4079, July 2005.
Schulzrinne, et al. Expires July 9, 2007 [Page 27]
Internet-Draft Geolocation Policy January 2007
[13] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-08 (work in progress),
October 2006.
[14] Thomson, M., "Geodetic Shapes for the Representation of
Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03
(work in progress), December 2006.
[15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
Schulzrinne, et al. Expires July 9, 2007 [Page 28]
Internet-Draft Geolocation Policy January 2007
Appendix A. Acknowledgments
This document is informed by the discussions within the IETF GEOPRIV
working group, including discussions at the GEOPRIV interim meeting
in Washington, D.C., in 2003.
We particularly want to thank Allison Mankin <mankin@psg.com>,
Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
Peterson <jon.peterson@neustar.biz> for their help in improving the
quality of this document.
We would like to thank Christian Guenther for his help with an
earlier version of this document. Furthermore, we would like to
thank Johnny Vrancken for a several document reviews and the
suggestions he provided between September and December 2006. James
Winterbottom provided a detailed review in November 2006.
This document uses text from [14]. Therefore, we would like to thank
Martin Thomson for his work on [14].
Schulzrinne, et al. Expires July 9, 2007 [Page 29]
Internet-Draft Geolocation Policy January 2007
Authors' Addresses
Henning Schulzrinne (editor)
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7042
Email: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig (editor)
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
John B. Morris, Jr.
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
USA
Email: jmorris@cdt.org
URI: http://www.cdt.org
Jorge R. Cuellar
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Jorge.Cuellar@siemens.com
Schulzrinne, et al. Expires July 9, 2007 [Page 30]
Internet-Draft Geolocation Policy January 2007
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Email: jmpolk@cisco.com
Schulzrinne, et al. Expires July 9, 2007 [Page 31]
Internet-Draft Geolocation Policy January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Schulzrinne, et al. Expires July 9, 2007 [Page 32]
