GEOPRIV H. Schulzrinne
Internet-Draft Columbia U.
Intended status: Standards Track H. Tschofenig
Expires: June 13, 2007 Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
Cisco
December 10, 2006
Geolocation Policy: A Document Format for Expressing Privacy Preferences
for Location Information
draft-ietf-geopriv-policy-09.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 June 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Schulzrinne, et al. Expires June 13, 2007 [Page 1]
Internet-Draft Geolocation Policy December 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Basic Data Model and Processing . . . . . . . . . . . . . 7
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 7
4. Location-specific Conditions . . . . . . . . . . . . . . . . . 8
4.1. Civic Location Condition . . . . . . . . . . . . . . . . . 8
4.2. Geospatial Location Condition . . . . . . . . . . . . . . 8
4.2.1. Polygon . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . 9
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 11
6.2. Set Retention-Expires . . . . . . . . . . . . . . . . . . 11
6.3. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 11
6.4. Provide Location Information . . . . . . . . . . . . . . . 12
6.4.1. Provide Civic Location Information . . . . . . . . . . 12
6.4.2. Provide Geospatial Location Information . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Rule Example with Civic Location Condition . . . . . . . . 15
7.2. Rule Example with Civic Transformations . . . . . . . . . 16
7.3. Rule Example with Geospatial Location Information . . . . 17
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Schulzrinne, et al. Expires June 13, 2007 [Page 2]
Internet-Draft Geolocation Policy December 2006
1. Introduction
Location information needs to be protected against unauthorized
access to preserve the privacy of the subject of the location
information. 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 information, and
a Rulemaker (RM) that provides authorization policy rules. 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 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. It does not allow to
customize information to specific Location Recipients, for example.
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
limited.
The sequence of operations is as follows. The 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 combined
permission 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 June 13, 2007 [Page 3]
Internet-Draft Geolocation Policy December 2006
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,
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 how a Location Server
handles Location Objects; it might limit when and how data and policy
can be distributed and may modify the information elements that are
returned to the requestor, e.g., reducing the granularity of location
information).
The XML schema defined in Section 8 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 June 13, 2007 [Page 4]
Internet-Draft Geolocation Policy December 2006
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 [7] uses the term presentity to describe the
entity that provides presence information to a presence service.
In a presence system, the Target is the presentity.
Watcher or Location Recipient:
The receiver of location information is the Location Recipient
(LR) in the terminology of RFC 3693 [1]. A watcher, i.e., an
entity that requests presence information about a presentity, is a
Location Recipient in presence systems.
Authorization policy:
An authorization policy is given by a rule set. A rule set
contains an unordered list of rules. A rule has a conditions, an
actions and a transformations part.
Permission:
The term permission indicates 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
protocol that is used to request access to and to return privacy
sensitive data items.
Schulzrinne, et al. Expires June 13, 2007 [Page 5]
Internet-Draft Geolocation Policy December 2006
Note that this document often points to Location Servers as the
entities that evaluate the authorization policies described in this
document. The Geopriv location privacy architecture is, as motivated
in RFC 4079 [8], aligned with the presence architecture and hence one
might see a Presence Server as an entity that distributes location
information along many other XML data elements.
Schulzrinne, et al. Expires June 13, 2007 [Page 6]
Internet-Draft Geolocation Policy December 2006
3. Generic Processing
3.1. Basic Data Model and Processing
Since this document is an extension of the Common Policy framework
defined in [3], it 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 or at a 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) [9].
Schulzrinne, et al. Expires June 13, 2007 [Page 7]
Internet-Draft Geolocation Policy December 2006
4. Location-specific Conditions
This section describes the location-specific conditions in a rule,
namely the civic and geospatial location conditions. The elements
<civic-location> and <geo-location> are child elements of the
<location> element. The <location> evaluates to TRUE if any of its
child elements is TRUE, i.e., a logical OR. The XML elements and
attributes shown below are defined by the XML schema in Section 8.
4.1. Civic Location Condition
The <civic-location> element matches if the current location of the
Target matches all the values specified in the child elements of this
element. The <civic-location> is of the 'civicAddress' complex type
defined in [5]. All child elements of <civic-location> element MUST
evaluate to TRUE (i.e., logical AND) in order for the <civic-
location> element to evaluate to TRUE.
If the civic location of the Target is not known, then the child
elements of <civic-location> element will evaluate to FALSE and the
civic location condition 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 geospatial
location is known.
4.2. Geospatial Location Condition
The geospatial location condition allows to make authorization
decisions based on the current geospatial location of the Target.
The geospatial location condition matches if the current location of
the Target is contained in either the identified polygon (see
Section 4.2.1) or between a range of altitude values (see
Section 4.2.2). If the geospatial location of the Target is not
known, the geospatial location condition evaluates to FALSE.
4.2.1. Polygon
The condition matches if the longitude and latitude values of the
polygon, interpreted as x and y coordinates on a plane, enclose the
current location of the target.
There are a number of algorithms for determining whether a point is
inside a polygon. A common algorithm draws a ray from the test point
to the right. The test point is inside if and only if the ray
intersects the line segments making up the polygon an odd number of
times.
The listed points, which constitute the polygon, MUST be listed as
Schulzrinne, et al. Expires June 13, 2007 [Page 8]
Internet-Draft Geolocation Policy December 2006
they appear in a clockwise direction all the way around the perimeter
of the single plane shape. This is the defined concept of a "Ring"
within GML [10]. The final point MUST be a repeat of the first point
listed to enclose the polygon.
4.2.2. Altitude
The altitude condition matches if the Target altitude is defined and
falls between the low and high altitude stated in the rule, measured
in meters above the WGS84 sphere. If either element is omitted, the
altitude range is an open range.
Schulzrinne, et al. Expires June 13, 2007 [Page 9]
Internet-Draft Geolocation Policy December 2006
5. Actions
This document does not define location-specific actions.
Schulzrinne, et al. Expires June 13, 2007 [Page 10]
Internet-Draft Geolocation Policy December 2006
6. Transformations
This document defines several elements that allow Rule Makers to
specify transformations to limit the accuracy of the Location Object
passed to the Location Recipient.
6.1. Set Retransmission-Allowed
This element ask the LS to change the value of the 'retransmission-
allowed' element in the PIDF-LO. The data type of the <set-
retransmission-allowed> element is Boolean.
If the value of the <set-retransmission-allowed> element is set to
TRUE then the 'retransmission-allowed' element in the PIDF-LO has 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 has 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 is kept
unchanged or, if the PIDF-LO is created for the first time, then the
value is set to FALSE.
6.2. Set Retention-Expires
This transformation asks the LS to change the value of the
'retention-expires' element in the PIDF-LO. The data type of the
<set-retention-expires> element is 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 is set
to 0, i.e., immediate expiry.
6.3. 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 Integer.
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
Schulzrinne, et al. Expires June 13, 2007 [Page 11]
Internet-Draft Geolocation Policy December 2006
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.4. Provide Location Information
The <provide-location> element contains the <provide-civic> and the
<provide-geo> child elements that control the granularity of location
information being made available. If the <provide-location> element
is provided without child elements then civic as well as geospatial
location information is provided without reducing its granularity,
subject to availability.
6.4.1. Provide Civic Location Information
The civic location transformation can be specified by means of the
<provide-civic> element to restrict the level of civic location
information the LS is permitted to provide. 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 [5]. 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:
Schulzrinne, et al. Expires June 13, 2007 [Page 12]
Internet-Draft Geolocation Policy December 2006
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>}
|
|
{ }
If the <provide-civic> element is absent, then civic location
information MUST NOT be disclosed.
6.4.2. Provide Geospatial Location Information
The geospatial location transformation can be specified by means of
the <provide-geo> element to restrict the resolution of the
geospatial location information to the value provided in the
<latitude-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 to the recipient of the Location Object 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 r that are not integer powers
of 10 or r > 1. For example, to round longitude to timezone
Schulzrinne, et al. Expires June 13, 2007 [Page 13]
Internet-Draft Geolocation Policy December 2006
accuracy, one would use r=15 and obtain a value of 75 in this
example.
If the <provide-geo> element is absent, then geospatial location
information MUST NOT be disclosed.
Schulzrinne, et al. Expires June 13, 2007 [Page 14]
Internet-Draft Geolocation Policy December 2006
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 which matches if the current location of the
Target is inside the area specified by the child elements of the
<civic-location> element. In this example, 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'.
The rule is valid for one year as specified by the <validity>
element.
No actions and transformation child elements are provided in this
rule example. In a real-world example, the actions and
transformation could include presence specific information when the
Geolocation Policy framework is applied to the Presence Policy
framework (see [11]).
Schulzrinne, et al. Expires June 13, 2007 [Page 15]
Internet-Draft Geolocation Policy December 2006
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cp:rule id="AA56i09">
<cp:conditions>
<cp:validity>
<cp:from>2004-11-01T00:00:00+01:00</cp:from>
<cp:until>2005-11-01T00:00:00+01:00</cp:until>
</cp:validity>
<gp:location>
<gp:civic-location>
<gp:country>DE</gp:country>
<gp:A1>Bavaria</gp:A1>
<gp:A3>Munich</gp:A3>
<gp:A4>Perlach</gp:A4>
<gp:A6>Otto-Hahn-Ring</gp:A6>
<gp:HNO>6</gp:HNO>
</gp:civic-location>
</gp:location>
</cp:conditions>
<cp:actions/>
<cp:transformations/>
</cp:rule>
</cp:ruleset>
7.2. Rule Example with Civic Transformations
This example contains a rule with an identity, a validity and a
sphere condition. Location specific transformations set elements in
the basic rules of the PIDF-LO, regarding retransmission, retention
and the ruleset reference. The <provide-civic> element indicates
that the available civic location information is reduced to building
level granularity.
Schulzrinne, et al. Expires June 13, 2007 [Page 16]
Internet-Draft Geolocation Policy December 2006
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="AA56i09">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:set-retransmission-allowed>false
</gp:set-retransmission-allowed>
<gp:set-retention-expires>86400</gp:set-retention-expires>
<gp:keep-rule-reference>false</gp:keep-rule-reference>
<gp:provide-location>
<gp:provide-civic>building</gp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
7.3. Rule Example with Geospatial Location Information
This example illustrates a rule that employs the geospatial location
condition. The rule matches if the current location of the Target is
inside the area specified by the <point> child elements of the
<polygon> element. The individual points of the polygon have to be
interpreted as points of the WGS-84 coordinate reference system, as
specified by the value of the 'crsName' attribute of the <polygon>
element. This coordinate reference systems is also used by GPS. The
given four points specify a quadrangle on the surface of the
rotational ellipoid being part of the WGS-84 system, corresponding to
a certain area in Washington, DC, USA.
The transformation part of the example rule allows the Location
Server to distribute Location Objects with the ruleset reference
removed. The Location Server is permitted to retain the Location
Objects related to the Target for at most one day. They are allowed
to provide civic location information about the Target at building
level of precision, and geospatial location information at roughly
Schulzrinne, et al. Expires June 13, 2007 [Page 17]
Internet-Draft Geolocation Policy December 2006
the first decimal of precision.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="BB56A19">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
<validity>
<from>2004-11-01T00:00:00+01:00</from>
<until>2005-11-01T00:00:00+01:00</until>
</validity>
<gp:location>
<gp:geo-location>
<gp:polygon
crsName="urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84">
<gp:point>
<gp:lat>38.8986</gp:lat>
<gp:lon>-77.03724</gp:lon>
</gp:point>
<gp:point>
<gp:lat>38.8986</gp:lat>
<gp:lon>-77.03722</gp:lon>
</gp:point>
<gp:point>
<gp:lat>38.8987</gp:lat>
<gp:lon>-77.03722</gp:lon>
</gp:point>
<gp:point>
<gp:lat>38.8987</gp:lat>
<gp:lon>-77.03724</gp:lon>
</gp:point>
</gp:polygon>
</gp:geo-location>
</gp:location>
</conditions>
<transformations>
<gp:set-retransmission-allowed>true
</gp:set-retransmission-allowed>
<gp:set-retention-expires>86400</gp:set-retention-expires>
Schulzrinne, et al. Expires June 13, 2007 [Page 18]
Internet-Draft Geolocation Policy December 2006
<gp:keep-rule-reference>false</gp:keep-rule-reference>
<gp:provide-location>
<gp:provide-civic>building</gp:provide-civic>
<gp:provide-geo>
<gp:lat-resolution>0.3</gp:lat-resolution>
<gp:lon-resolution>0.2</gp:lon-resolution>
</gp:provide-geo>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
The next ruleset indicates that the Target has to be at an altitude
between 1500 and 4000 meters in order for this rule to match.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="BB56A19">
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
<gp:location>
<gp:geo-location>
<gp:altitude>
<gp:min>1500.0</gp:min>
<gp:max>4000.0</gp:max>
</gp:altitude>
</gp:geo-location>
</gp:location>
</conditions>
<transformations>
<gp:provide-location/>
</transformations>
</rule>
</ruleset>
Schulzrinne, et al. Expires June 13, 2007 [Page 19]
Internet-Draft Geolocation Policy December 2006
8. XML Schema
This section presents the XML schema that defines the Geolocation
Policy schema described in the previous sections. 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>).
To express civic location conditions, it imports the 'civicAddress'
complex type as defined in [5].
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-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">
<!-- Geopriv Conditions -->
<xs:element name="location">
<xs:complexType>
<xs:choice>
<xs:element name="civic-location" type="cl:civicAddress"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="geo-location" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="polygon">
<xs:complexType>
<xs:sequence>
<xs:element name="point" minOccurs="3"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="lat" type="xs:double"/>
<xs:element name="lon" type="xs:double"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="crsName" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
Schulzrinne, et al. Expires June 13, 2007 [Page 20]
Internet-Draft Geolocation Policy December 2006
<xs:element name="altitude">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="min" type="xs:double"/>
<xs:element name="max" type="xs:double"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
<!-- 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="keep-rule-reference" type="xs:boolean"
default="false"/>
<xs:element name="provide-location">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="provide-civic" minOccurs="0" maxOccurs="1">
<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>
<xs:element name="provide-geo" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="lat-resolution" type="xs:double"
minOccurs="0" maxOccurs="1"/>
<xs:element name="lon-resolution" type="xs:double"
minOccurs="0" maxOccurs="1"/>
<xs:element name="alt-resolution" type="xs:double"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
Schulzrinne, et al. Expires June 13, 2007 [Page 21]
Internet-Draft Geolocation Policy December 2006
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Schulzrinne, et al. Expires June 13, 2007 [Page 22]
Internet-Draft Geolocation Policy December 2006
9. 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 [6] 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 June 13, 2007 [Page 23]
Internet-Draft Geolocation Policy December 2006
10. References
10.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] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in
progress), September 2006.
[6] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
10.2. Informative References
[7] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[8] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", RFC 4079, July 2005.
[9] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12 (work in progress), October 2006.
[10] OpenGIS, "OpenGIS Geography Markup Language (GML)
Implementation Specification, Version 3.00, OGC 02 023r4",
http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003.
[11] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-08 (work in progress),
October 2006.
[12] 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 June 13, 2007 [Page 24]
Internet-Draft Geolocation Policy December 2006
Appendix A. Contributors
We would like to thank Christian Guenther for his help with an
earlier version of this document.
Schulzrinne, et al. Expires June 13, 2007 [Page 25]
Internet-Draft Geolocation Policy December 2006
Appendix B. 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 Johnny Vrancken for his review and the
suggestions he provided in September 2006. James Winterbottom
provided a review in November 2006.
Schulzrinne, et al. Expires June 13, 2007 [Page 26]
Internet-Draft Geolocation Policy December 2006
Authors' Addresses
Henning Schulzrinne
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
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 June 13, 2007 [Page 27]
Internet-Draft Geolocation Policy December 2006
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Email: jmpolk@cisco.com
Schulzrinne, et al. Expires June 13, 2007 [Page 28]
Internet-Draft Geolocation Policy December 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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 June 13, 2007 [Page 29]
