[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, Ed.
Internet-Draft                                       Columbia University
Intended status: Standards Track                      H. Tschofenig, Ed.
Expires: November 23, 2007                        Nokia Siemens Networks
                                                               J. Morris
                                                                     CDT
                                                              J. Cuellar
                                                                 Siemens
                                                                 J. Polk
                                                                   Cisco
                                                            May 22, 2007


Geolocation Policy: A Document Format for Expressing Privacy Preferences
                        for Location Information
                    draft-ietf-geopriv-policy-12.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 November 23, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).






Schulzrinne, et al.     Expires November 23, 2007               [Page 1]

Internet-Draft             Geolocation Policy                   May 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 in order 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.  Structure of Geolocation Authorization Documents . . . . .  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-Expiry . . . . . . . . . . . . . . . . . . . 12
     6.3.  Set Note-Well  . . . . . . . . . . . . . . . . . . . . . . 12
     6.4.  Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13
     6.5.  Provide Location . . . . . . . . . . . . . . . . . . . . . 13
       6.5.1.  Civic Location Profile . . . . . . . . . . . . . . . . 14
       6.5.2.  Geodetic Location Profile  . . . . . . . . . . . . . . 15
   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 Basic Location Profiles . . . . . . . . . . . . 22
   9.  XML Schema for Geolocation Policy  . . . . . . . . . . . . . . 23
   10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Application Unique ID  . . . . . . . . . . . . . . . . . . 25
     10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.3. Default Namespace  . . . . . . . . . . . . . . . . . . . . 25
     10.4. MIME Type  . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25
     10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25
     10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25
     10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26
     10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26



Schulzrinne, et al.     Expires November 23, 2007               [Page 2]

Internet-Draft             Geolocation Policy                   May 2007


   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     11.1. Geolocation Policy XML Schema Registration . . . . . . . . 27
     11.2. Geolocation Policy Namespace Registration  . . . . . . . . 27
     11.3. Geolocation Policy Location Profile Registry . . . . . . . 28
     11.4. Basic Location Profile XML Schema Registration . . . . . . 28
     11.5. Basic Location Profile Namespace Registration  . . . . . . 29
     11.6. XCAP Application Usage ID  . . . . . . . . . . . . . . . . 29
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     13.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 37





































Schulzrinne, et al.     Expires November 23, 2007               [Page 3]

Internet-Draft             Geolocation Policy                   May 2007


1.  Introduction

   Location information needs to be protected against unauthorized
   access to preserve the privacy of humans.  In RFC 3693 [6], 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) [7] 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 [6].  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 [1].  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 the protocol used to convey location



Schulzrinne, et al.     Expires November 23, 2007               [Page 4]

Internet-Draft             Geolocation Policy                   May 2007


   information from the Location Server to the Location Recipient (i.e.,
   the using protocol; see RFC 3693 [6]).

   This document extends the Common Policy framework defined in [1].
   That document provides an abstract framework for expressing
   authorization 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 modifies 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 November 23, 2007               [Page 5]

Internet-Draft             Geolocation Policy                   May 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 [2].

   This document reuses the terminology of RFC 3693 [6], such as
   Location Server (LS), Location Recipient (LR), Rule Maker (RM),
   Target, Location Generator (LG) and Location Object (LO).  This
   document uses the following terminology:

   Presentity or Target:

      RFC 3693 [6] uses the term Target to identify the object or person
      of which location information is required.  The presence model
      described in RFC 2778 [8] 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 [6].  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 (policy) 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 term 'using protocol' is defined in [6] and refers to the
   protocol that is used to request access to and to return privacy
   sensitive data items.

   In this document we use the term Location Servers as the entities
   that evaluate the geolocation authorization policies.  The



Schulzrinne, et al.     Expires November 23, 2007               [Page 6]

Internet-Draft             Geolocation Policy                   May 2007


   geolocation privacy architecture is, as motivated in RFC 4079 [9],
   aligned with the presence architecture and a Presence Server is
   therefore an entity that distributes location information along with
   other presence-specific XML data elements.















































Schulzrinne, et al.     Expires November 23, 2007               [Page 7]

Internet-Draft             Geolocation Policy                   May 2007


3.  Generic Processing

3.1.  Structure of Geolocation Authorization Documents

   A geolocation authorization document is an XML document, formatted
   according to the schema defined in [1].  Geolocation authorization
   documents inherit the MIME type of common policy documents,
   application/auth-policy+xml.  As described in [1], this document is
   composed of rules which contain three parts - conditions, actions,
   and transformations.  Each action or transformation, which is also
   called a permission, has the property of being a positive grant of
   information to the Location Recipient.  As a result, there is a well-
   defined mechanism for combining actions and transformations obtained
   from several sources.  This mechanism is privacy safe, since the lack
   of any action or transformation can only result in less information
   being presented to a Location Recipient.

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 [7] 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 November 23, 2007               [Page 8]

Internet-Draft             Geolocation Policy                   May 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 contains 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 this 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 [3]
   <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.

   Implementations are REQUIRED to support the following coordinate
   reference systems based on WGS 84 [4].  These are identified using
   the European Petroleum Survey Group (EPSG) Geodetic Parameter
   Dataset, as formalized by the Open Geospatial Consortium (OGC):








Schulzrinne, et al.     Expires November 23, 2007               [Page 9]

Internet-Draft             Geolocation Policy                   May 2007


   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.


   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.

   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:
   LinearRing" element.  Implementations SHOULD minimize this
   interpolation error by ensuring that the sides of polygons are as
   short as possible.

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 [5], 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.

   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 November 23, 2007              [Page 10]

Internet-Draft             Geolocation Policy                   May 2007


5.  Actions

   This document does not define location-specific actions.
















































Schulzrinne, et al.     Expires November 23, 2007              [Page 11]

Internet-Draft             Geolocation Policy                   May 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 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-Expiry

   This transformation asks the LS to change or set the value of the
   <retention-expiry> element in the PIDF-LO.  The data type of the
   <set-retention-expiry> element is an integer.

   The value provided with the <set-retention-expiry> element indicates
   seconds and these seconds are added to the current date.

   If the <set-retention-expiry> element is absent then the value of the
   <retention-expiry> 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 the current date.

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 November 23, 2007              [Page 12]

Internet-Draft             Geolocation Policy                   May 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 <external-
   ruleset> element in the PIDF-LO carries the extended authorization
   rules defined in [1].  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 <external-ruleset> element in the PIDF-LO is kept unchanged
   when included.  If the value of the <keep-rule-reference> element is
   set to FALSE, then the <external-ruleset> 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
   <external-ruleset> element in the PIDF-LO is kept unchanged when
   available or, if the PIDF-LO is created for the first time then the
   <external-ruleset> element MUST NOT be included.

6.5.  Provide Location

   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, namely:


   o  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.


   o  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.


   The <provide-location> element MUST contain the 'profile' attribute
   if it contains child elements and the 'profile' attribute MUST match
   with the contained child elements.  The <provide-location> element
   MUST contain the 'profile' attribute if it contains child elements.




Schulzrinne, et al.     Expires November 23, 2007              [Page 13]

Internet-Draft             Geolocation Policy                   May 2007


   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.  In this case the
   profile attribute MUST NOT be included.

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
   <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 [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.


                              full
      {<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
       <STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,
       <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>,
         <RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
                               |
                               |
                             city
                     {<country>, <A1>, <A2>, <A3>}
                               |
                               |
                             region
                        {<country>, <A1>}
                               |
                               |
                            country
                          {<country>}
                               |
                               |
                              none



Schulzrinne, et al.     Expires November 23, 2007              [Page 14]

Internet-Draft             Geolocation Policy                   May 2007


                              {}

   The default value is "none".

   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' and refers only
   to the Coordinate Reference System (CRS) WGS 84
   (urn:ogc:def:crs:EPSG::4326, 2D) and WGS 84
   (urn:ogc:def:crs:EPSG::4979, 3D).  This profile allows geodetic
   location transformations to be specified by means of the <provide-
   geo> element that restricts the resolution of geodetic location
   information based on 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 real
   number r.  Assume that the variable n represents the nominal
   coordinate value (longitude, latitude or altitude), the rounded value
   is computed as

      n'=FLOOR(n*r + 0.5) * 1/r

   Small r values indicate that the granularity of the returned location
   information will be reduced.  The smaller the value r is the larger
   is the granularity reduction.  The value '0' is used to indicate that
   location MUST NOT be distributed.  Per default the value '0' is
   assumed.  A large r value indicates that a large amount of the
   available location information will be distributed.  The larger the
   value r is the more precise the returned location information is.
   The maximum is infinity, the symbol "INF", indicating that the
   available information is disclosed without reduction of the
   granularity.

   Next, we show an example where we assume a nominal latitude value of
   n=38.89868.

               Value r        Computed n'
               ---------------------------
                  0.01          89.0000
                  0.1           43.9000
                  1             39.4000
                 10             38.9490
                100             38.9037

   The schema of the <provide-geo> element is defined in Section 8.





Schulzrinne, et al.     Expires November 23, 2007              [Page 15]

Internet-Draft             Geolocation Policy                   May 2007


7.  Examples

   This section provides a few examples for authorization 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.  It matches if the current location of the Target
   equal 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 [11]).


   <?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">

     <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 November 23, 2007              [Page 16]

Internet-Draft             Geolocation Policy                   May 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.


   <?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">

     <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 November 23, 2007              [Page 17]

Internet-Draft             Geolocation Policy                   May 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">

     <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 November 23, 2007              [Page 18]

Internet-Draft             Geolocation Policy                   May 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">

     <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 November 23, 2007              [Page 19]

Internet-Draft             Geolocation Policy                   May 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:lp="urn:ietf:params:xml:ns:basic-location-profiles">

     <rule id="AA56i09">
       <conditions/>
       <actions/>
       <transformations>
         <gp:set-retransmission-allowed>false
         </gp:set-retransmission-allowed>
         <gp:set-retention-expiry>86400</gp:set-retention-expiry>
         <gp:set-note-well xml:lang="en">My privacy policy goes in here.
         </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>

   The following rule describes the short-hand notation for making the
   current location of the Target available to Location Recipients
   without granularity reduction.









Schulzrinne, et al.     Expires November 23, 2007              [Page 20]

Internet-Draft             Geolocation Policy                   May 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">

               <rule id="AA56ia9">
                 <conditions/>
                 <actions/>
                 <transformations>
                   <gp:provide-location/>
                 </transformations>
               </rule>
             </ruleset>







































Schulzrinne, et al.     Expires November 23, 2007              [Page 21]

Internet-Draft             Geolocation Policy                   May 2007


8.  XML Schema for Basic 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:basic-location-profiles"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

       <!-- profile="civic-transformation" -->

       <xs:element name="provide-civic" default="none">
       <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:enumeration value="none"/>
           </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" default="0"/>
               <xs:element name="longitude-resolution"
                   type="xs:double" minOccurs="0"
                   maxOccurs="1" default="0"/>
               <xs:element name="altitude-resolution"
                   type="xs:double" minOccurs="0"
                   maxOccurs="1" default="0"/>
           </xs:sequence>
       </xs:complexType>
       </xs:element>

   </xs:schema>



Schulzrinne, et al.     Expires November 23, 2007              [Page 22]

Internet-Draft             Geolocation Policy                   May 2007


9.  XML Schema for Geolocation Policy

   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 [1]) 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:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

     <!-- Import Common Policy-->
     <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>

     <!-- 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"
                 minOccurs="1" maxOccurs="unbounded"/>
               <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"/>



Schulzrinne, et al.     Expires November 23, 2007              [Page 23]

Internet-Draft             Geolocation Policy                   May 2007


           </xs:choice>
           <xs:attribute name="profile" type="xs:string"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <!-- Geopriv transformations -->
     <xs:element name="set-retransmission-allowed"
       type="xs:boolean" default="false"/>
     <xs:element name="set-retention-expiry"
       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="0" maxOccurs="unbounded">
           <xs:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded"/>
           </xs:choice>
           <xs:attribute name="profile" type="xs:string" />
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

   </xs:schema>










Schulzrinne, et al.     Expires November 23, 2007              [Page 24]

Internet-Draft             Geolocation Policy                   May 2007


10.  XCAP Usage

   The following section defines the details necessary for clients to
   manipulate geolocation privacy documents from a server using XCAP.
   If used as part of a presence system, it uses the same AUID as those
   rules.  See [11] for a description of the XCAP usage in context with
   presence authorization rules.

10.1.  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the "geolocation-policy" AUID within the IETF
   tree, via the IANA registration in Section 11.

10.2.  XML Schema

   XCAP requires application usages to define a schema for their
   documents.  The schema for geolocation authorization documents is
   described in Section 9.

10.3.  Default Namespace

   XCAP requires application usages to define the default namespace for
   their documents.  The default namespace is
   urn:ietf:params:xml:ns:geolocation-policy.

10.4.  MIME Type

   XCAP requires application usages to defined the MIME type for
   documents they carry.  Geolocation privacy authorization documents
   inherit the MIME type of common policy documents, application/
   auth-policy+xml.

10.5.  Validation Constraints

   This specification does not define additional constraints.

10.6.  Data Semantics

   This document discusses the semantics of a geolocation privacy
   authorization.

10.7.  Naming Conventions

   When a Location Server receives a request to access location
   information of some user foo, it will look for all documents within
   http://[xcaproot]/geolocation-policy/users/foo, and use all documents



Schulzrinne, et al.     Expires November 23, 2007              [Page 25]

Internet-Draft             Geolocation Policy                   May 2007


   found beneath that point to guide authorization policy.

10.8.  Resource Interdependencies

   This application usage does not define additional resource
   interdependencies.

10.9.  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which is that only a user can read, write or modify his/her
   own documents.  A server can allow privileged users to modify
   documents that they do not own, but the establishment and indication
   of such policies is outside the scope of this document.





































Schulzrinne, et al.     Expires November 23, 2007              [Page 26]

Internet-Draft             Geolocation Policy                   May 2007


11.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

11.1.  Geolocation Policy XML Schema Registration

   URI:  urn:ietf:params:xml:schema:geolocation-policy

   Registrant Contact:  IETF Geopriv Working Group, Hannes Tschofenig
      (hannes.tschofenig@nsn.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>

11.2.  Geolocation Policy Namespace Registration

   URI:  urn:ietf:params:xml:ns:geolocation-policy

   Registrant Contact:  IETF Geopriv Working Group, Hannes Tschofenig
      (hannes.tschofenig@nsn.com).

   XML:






















Schulzrinne, et al.     Expires November 23, 2007              [Page 27]

Internet-Draft             Geolocation Policy                   May 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

11.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 [12],
   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.

11.4.  Basic Location Profile XML Schema Registration

   URI:  urn:ietf:params:xml:schema:basic-location-profiles

   Registrant Contact:  IETF Geopriv Working Group, Hannes Tschofenig
      (hannes.tschofenig@nsn.com).







Schulzrinne, et al.     Expires November 23, 2007              [Page 28]

Internet-Draft             Geolocation Policy                   May 2007


   XML:  The XML schema to be registered is contained in Section 8.  Its
      first line is

   <?xml version="1.0" encoding="UTF-8"?>

      and its last line is

   </xs:schema>

11.5.  Basic Location Profile Namespace Registration

   URI:  urn:ietf:params:xml:ns:basic-location-profiles

   Registrant Contact:  IETF Geopriv Working Group, Hannes Tschofenig
      (hannes.tschofenig@nsn.com).

   XML:

   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>Basic Location Profile Namespace</title>
   </head>
   <body>
     <h1>Namespace for Basic Location Profile</h1>
     <h2>urn:ietf:params:xml:schema:basic-location-profiles</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

11.6.  XCAP Application Usage ID

   This section registers an XCAP Application Usage ID (AUID) according
   to the IANA procedures defined in [10].

   Name of the AUID: geolocation-policy

   Description: Geolocation privacy rules are documents that describe
   the permissions that a Target has granted to Location Recipients that



Schulzrinne, et al.     Expires November 23, 2007              [Page 29]

Internet-Draft             Geolocation Policy                   May 2007


   access information about his/her geographic location.


















































Schulzrinne, et al.     Expires November 23, 2007              [Page 30]

Internet-Draft             Geolocation Policy                   May 2007


12.  Security Considerations

   This document aims to make it simple for users to prevent the
   unintended disclosure of private information to third parties.  This
   is accomplished through the usage of authorization policies.
   Security requirements are described in [6] and a discussion of
   generic security threats is available with [13].  Aspects of
   combining permissions in cases of multiple occurrence are treated in
   [1]).  The concept of location-based conditions are introduced in
   Section 4 and mechanisms to reduce the granularity of returned
   location information is specified in Section 6.








































Schulzrinne, et al.     Expires November 23, 2007              [Page 31]

Internet-Draft             Geolocation Policy                   May 2007


13.  References

13.1.  Normative References

   [1]   Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
         J., and J. Rosenberg, "Common Policy: A Document Format for
         Expressing Privacy Preferences", RFC 4745, February 2007.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", March 1997.

   [3]   OpenGIS, "OpenGIS Geography Markup Language (GML)
         Implementation Specification, Version 3.00, OGC 02 023r4",
          http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003.

   [4]   OpenGIS, "US National Imagery and Mapping Agency, "Department
         of Defense (DoD) World Geodetic System 1984 (WGS 84), Third
         Edition, NIMA TR8350.2",   , January 2000.

   [5]   Thomson, M. and J. Winterbottom, "Revised Civic Location Format
         for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
         progress), February 2007.

13.2.  Informative References

   [6]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
         Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [7]   Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [8]   Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

   [9]   Peterson, J., "A Presence Architecture for the Distribution of
         GEOPRIV Location Objects", RFC 4079, July 2005.

   [10]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
         draft-ietf-simple-xcap-12 (work in progress), October 2006.

   [11]  Rosenberg, J., "Presence Authorization Rules",
         draft-ietf-simple-presence-rules-09 (work in progress),
         March 2007.

   [12]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.



Schulzrinne, et al.     Expires November 23, 2007              [Page 32]

Internet-Draft             Geolocation Policy                   May 2007


   [13]  Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
         Analysis of the Geopriv Protocol", RFC 3694, February 2004.

   [14]  Thomson, M., "Geodetic Shapes for the Representation of
         Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03
         (work in progress), December 2006.













































Schulzrinne, et al.     Expires November 23, 2007              [Page 33]

Internet-Draft             Geolocation Policy                   May 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 his document reviews in September 2006,
   December 2006 and January 2007.  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 in [14].

   We would like to thank Dan Romascanu, Yoshiko Chong and Jari
   Urpalainen for their last call comments.




























Schulzrinne, et al.     Expires November 23, 2007              [Page 34]

Internet-Draft             Geolocation Policy                   May 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)
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.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 November 23, 2007              [Page 35]

Internet-Draft             Geolocation Policy                   May 2007


   James Polk
   Cisco
   2200 East President George Bush Turnpike
   Richardson, Texas  75082
   USA

   Email: jmpolk@cisco.com












































Schulzrinne, et al.     Expires November 23, 2007              [Page 36]

Internet-Draft             Geolocation Policy                   May 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 November 23, 2007              [Page 37]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/