[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 RFC 6772

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/