GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6772

Internet Engineering Task Force (IETF) H. Schulzrinne, Ed. Request for Comments: 6772 Columbia University Category: Standards Track H. Tschofenig, Ed. ISSN: 2070-1721 Nokia Siemens Networks

                                                            J. Cuellar
                                                               Siemens
                                                               J. Polk
                                                                 Cisco
                                                             J. Morris
                                                            M. Thomson
                                                             Microsoft
                                                          January 2013
             Geolocation Policy: A Document Format for
      Expressing Privacy Preferences for Location Information

Abstract

 This document defines an authorization policy language for
 controlling 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 to data
 based on the current location of the Target.
 Furthermore, this document defines two algorithms for reducing the
 granularity of returned location information.  The first algorithm is
 defined for usage with civic location information, whereas the other
 one applies to geodetic location information.  Both algorithms come
 with limitations.  There are circumstances where the amount of
 location obfuscation provided is less than what is desired.  These
 algorithms might not be appropriate for all application domains.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6772.

Schulzrinne, et al. Standards Track [Page 1] RFC 6772 Geolocation Policy January 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Schulzrinne, et al. Standards Track [Page 2] RFC 6772 Geolocation Policy January 2013

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  Generic Processing . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.  Structure of Geolocation Authorization Documents . . . . .  7
   3.2.  Rule Transport . . . . . . . . . . . . . . . . . . . . . .  7
 4.  Location-Specific Conditions . . . . . . . . . . . . . . . . .  7
   4.1.  Geodetic Location Condition Profile  . . . . . . . . . . .  8
   4.2.  Civic Location Condition Profile . . . . . . . . . . . . .  9
 5.  Actions  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
 6.  Transformations  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.1.  Set Retransmission-Allowed . . . . . . . . . . . . . . . .  9
   6.2.  Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 10
   6.3.  Set Note-Well  . . . . . . . . . . . . . . . . . . . . . . 10
   6.4.  Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 10
   6.5.  Provide Location . . . . . . . . . . . . . . . . . . . . . 11
     6.5.1.  Civic Location Profile . . . . . . . . . . . . . . . . 12
     6.5.2.  Geodetic Location Profile  . . . . . . . . . . . . . . 13
 7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.1.  Rule Example with Civic Location Condition . . . . . . . . 15
   7.2.  Rule Example with Geodetic Location Condition  . . . . . . 16
   7.3.  Rule Example with Civic and Geodetic Location Condition  . 17
   7.4.  Rule Example with Location-Based Transformations . . . . . 18
   7.5.  Location Obfuscation Example . . . . . . . . . . . . . . . 19
 8.  XML Schema for Basic Location Profiles . . . . . . . . . . . . 23
 9.  XML Schema for Geolocation Policy  . . . . . . . . . . . . . . 24
 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   10.1. Application Unique ID  . . . . . . . . . . . . . . . . . . 26
   10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 26
   10.3. Default Namespace  . . . . . . . . . . . . . . . . . . . . 26
   10.4. MIME Media Type  . . . . . . . . . . . . . . . . . . . . . 26
   10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 26
   10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 26
   10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 26
   10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26
   10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 27
 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. Internationalization Considerations  . . . . . . . . . . . . . 30
 13. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 30
   13.2. Obfuscation  . . . . . . . . . . . . . . . . . . . . . . . 31

Schulzrinne, et al. Standards Track [Page 3] RFC 6772 Geolocation Policy January 2013

   13.3. Algorithm Limitations  . . . . . . . . . . . . . . . . . . 32
   13.4. Usability  . . . . . . . . . . . . . . . . . . . . . . . . 33
   13.5. Limitations of Obscuring Locations . . . . . . . . . . . . 33
 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
   14.2. Informative References . . . . . . . . . . . . . . . . . . 35
 Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 38
 Appendix B.  Pseudocode  . . . . . . . . . . . . . . . . . . . . . 39

1. Introduction

 Location information needs to be protected against unauthorized
 access to preserve the privacy of humans.  In RFC 6280 [RFC6280], 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) [RFC4119] 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
 does not protect access to location information.  It only conveys the
 user's privacy preferences.  This document describes an enhanced rule
 set that provides richer constraints on the distribution of LOs.
 The enhanced 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 is reduced for parts
 of the Location Object.
 In the typical sequence of operations, a Location Server receives a
 query for location information for a particular Target.  The
 authenticated identity of the Location Recipient, together with other
 information provided with the request 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

Schulzrinne, et al. Standards Track [Page 4] RFC 6772 Geolocation Policy January 2013

 permission is evaluated according to the description in Section 10 of
 [RFC4745].  The result of the rule evaluation 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
 information from the Location Server to the Location Recipient.
 This document extends the Common Policy framework defined in
 [RFC4745].  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,
 such as a Location Server, is permitted to apply actions and
 transformations.  In a location information context, transformations
 regulate how a Location Server modifies the information elements that
 are returned to the requestor by, for example, reducing the
 granularity of returned location information.
 This document defines two algorithms for reducing the granularity of
 returned location information.  The first algorithm is defined for
 usage with civic location information (see Section 6.5.1) while the
 other one applies to geodetic location information (see
 Section 6.5.2).  Both algorithms come with limitations, i.e., they
 provide location obfuscation under certain conditions and may
 therefore not be appropriate for all application domains.  These
 limitations are documented within the Security Consideration section
 (see Section 13).  The geodetic transformation algorithm in
 Section 6.5.2 mitigates privacy risks for both stationary and moving
 Targets.  However, moving Targets will reveal additional information
 to an adversary.  To cover applications that have more sophisticated
 privacy requirements, additional algorithms may need to be defined.
 This document foresees extensions in the form of new algorithms and
 therefore defines a registry (see Section 11.3).
 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.

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

Schulzrinne, et al. Standards Track [Page 5] RFC 6772 Geolocation Policy January 2013

 This document reuses the terminology of RFC 6280 [RFC6280], 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 6280 [RFC6280] uses the term "Target" to identify the object
    or person of which location information is required.  The presence
    model described in RFC 2778 [RFC2778] 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 6280 [RFC6280].  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.
 Location Servers:
    Entities that evaluate the geolocation authorization policies.
 Presence Servers:
    The geolocation privacy architecture is, as described in RFC 4079
    [RFC4079], 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. Standards Track [Page 6] RFC 6772 Geolocation Policy January 2013

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 [RFC4745].  Geolocation
 authorization documents inherit the media type of Common Policy
 documents, application/auth-policy+xml.  As described in [RFC4745],
 this document is composed of rules that 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 enabling, 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 the authorization rules described in this document
 may be conveyed between different parties:
 o  RFC 4119 [RFC4119] 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) [RFC4825].

4. Location-Specific Conditions

 This section describes the location-specific conditions of a rule.
 The <conditions> element contains zero or more <location-condition>
 child element(s).  The <conditions> element only evaluates to TRUE if
 all child elements evaluate to TRUE; therefore, multiple <location-
 condition> elements are not normally useful.
 The <location-condition> element MUST contain at least one <location>
 child element.  The <location-condition> element evaluates to TRUE if
 any of its child <location> elements matches the location of the
 Target, i.e., <location> elements are combined using a logical OR.

Schulzrinne, et al. Standards Track [Page 7] RFC 6772 Geolocation Policy January 2013

 The three attributes of <location> are 'profile', 'xml:lang', and
 'label'.  The 'profile' indicates the location profile that is
 included as child elements in the <location> element.  Two location
 profiles, geodetic and civic, are defined in Sections 4.1 and 4.2.
 Each profile describes under what conditions a <location> element
 evaluates to TRUE.
 The 'label' attribute allows a human-readable description to be added
 to each <location> element.  The 'xml:lang' attribute contains a
 language tag providing further information for rendering of the
 content of the 'label' attribute.
 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.  This causes
 a <conditions> element to evaluate to FALSE if a <location-condition>
 element is unsupported.  A <location-condition> is considered TRUE if
 any of the <location> elements understood by the rule evaluator is
 TRUE.

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 Geography
 Markup Language [GML] <Circle> element within the <location> element
 (as described in Section 5.2.3 of [RFC5491]).
 The <location> element containing the information for the geodetic
 location profile evaluates to TRUE if the current location of the
 Target is completely within the described location (see Section
 6.1.15.3 of [OGC-06-103r4]).  Note that the Target's actual location
 might be represented by any of the location shapes described in
 [RFC5491].  If the geodetic location of the Target is unknown, then
 the <location> element containing the information for the geodetic
 location profile evaluates to FALSE.
 Implementations MUST support the World Geodetic System 1984 (WGS 84)
 [NIMA.TR8350.2-3e] coordinate reference system using the formal
 identifier from the European Petroleum Survey Group (EPSG) Geodetic
 Parameter Dataset (as formalized by the Open Geospatial Consortium
 (OGC)):
    2D: WGS 84 (latitude, longitude), as identified by the URN
    "urn:ogc:def:crs:EPSG::4326".  This is a two-dimensional CRS.
 A Coordinate Reference System (CRS) MUST be specified using the above
 URN notation only; implementations do not need to support user-
 defined CRSs.

Schulzrinne, et al. Standards Track [Page 8] RFC 6772 Geolocation Policy January 2013

 Implementations MUST specify the CRS using the "srsName" attribute on
 the outermost geometry element.  The CRS MUST NOT be changed for any
 sub-elements.  The "srsDimension" attribute MUST be omitted, since
 the number of dimensions in these CRSs is known.

4.2. Civic Location Condition Profile

 The civic location profile is identified by the token 'civic-
 condition'.  Rule Makers use this profile by placing a <civicAddress>
 element, defined in [RFC5139], within the <location> element.
 All child elements of a <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 child element, the
 value of that element is compared to the value of the same element in
 the Target's civic location.  The child element evaluates to TRUE if
 the two values are identical based on an octet-by-octet comparison.
 A <location> element containing a <civic-condition> profile evaluates
 to FALSE if a civic address is not present for the Target.  For
 example, this could occur if location information has been removed by
 other rules or other transmitters of location information or if only
 the geodetic location is known.  In general, it is RECOMMENDED
 behavior for an LS not to apply a translation from geodetic location
 to civic location (i.e., geocode the location).

5. Actions

 This document does not define location-specific actions.

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 specifies a change to or the creation of a value for 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>

Schulzrinne, et al. Standards Track [Page 9] RFC 6772 Geolocation Policy January 2013

 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 a non-negative integer.
 The value provided with the <set-retention-expiry> element indicates
 seconds, and these seconds are added to the time that the LS provides
 location.  A value of zero requests that the information is not
 retained.
 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'
 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 specifies whether the <external-ruleset> element
 in the PIDF-LO carries the extended authorization rules defined in
 [RFC4745].  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

Schulzrinne, et al. Standards Track [Page 10] RFC 6772 Geolocation Policy January 2013

 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 to an external rule set.  The reference to
 the ruleset is removed, and no rules are carried as MIME bodies (in
 case of Content-ID (cid:) URIs [RFC2392]).
 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 form of location granularity reduction is also
 called 'obfuscation' and is defined in [DUCKHAM05] as
    the means of deliberately degrading the quality of information
    about an individual's location in order to protect that
    individual's location privacy.
 Location obscuring presents a number of technical challenges.  The
 algorithms provided in this document are provided as examples only.
 A discussion of the technical constraints on location obscuring is
 included in Section 13.5.
 The functionality of location granularity reduction depends on the
 type of location provided as input.  This document defines two
 profiles for reduction, namely:
 o  civic-transformation: 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  geodetic-transformation: 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 child elements MUST be
 appropriate for the profile.
 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.

Schulzrinne, et al. Standards Track [Page 11] RFC 6772 Geolocation Policy January 2013

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', and 'full'.
 Each level is given by a set of civic location data items such as
 <country> and <A1>, ..., <POM>, as defined in [RFC5139].  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
                            {}
 The default value is "none".
 The schema of the <provide-civic> element is defined in Section 8.

Schulzrinne, et al. Standards Track [Page 12] RFC 6772 Geolocation Policy January 2013

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).  This profile allows geodetic
 location transformations to be specified by means of the <provide-
 geo> element that may restrict the returned geodetic location
 information based on the value provided in the 'radius' attribute.
 The value of the 'radius' attribute expresses the radius in meters.
 The schema of the <provide-geo> element is defined in Section 8.
 The algorithm proceeds in six steps.  The first two steps are
 independent of the measured position to be obscured and should be run
 only once or very infrequently for each region and desired
 uncertainty.  The steps are:
 1.  Choose a geodesic projection with Cartesian coordinates and a
     surface you want to cover.  Limit the worst-case distortion of
     the map as noted below.
 2.  Given a desired uncertainty radius "d", choose a grid of so-
     called "landmarks" at a distance of at least d units apart from
     each other.
 3.  Given a measured location M=(m,n) on the surface, calculate its 4
     closest landmarks on the grid, with coordinates: SW = (l,b),
     SE=(r,b), NW=(l,t), NE=(r,t).  Thus, l<=m<r and b<=n<t.  See
     notes below.
 4.  Let x=(m-l)/(r-l) and y=(n-b)/(t-b).
     x and y are thus the scaled local coordinates of the point M in
     the small grid square that contains it, where x and y range
     between 0 and 1.
 5.  Let p = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p).  Determine
     which of the following eight cases holds:
     C1. x < p and y < p
     C2. p <= x < q and y < x and y < 1-x
     C3. q <= x and y < p
     C4. p <= y < q and x <= y and y < 1-x
     C5. p <= y < q and y < x and 1-x <= y

Schulzrinne, et al. Standards Track [Page 13] RFC 6772 Geolocation Policy January 2013

     C6. x < p and q <= y
     C7. p <= x < q and x <= y and 1-x <= y
     C8. q <= x and q <= y
 6.  Depending on the case, let C (=Center) be
     C1: SW
     C2: SW or SE
     C3: SE
     C4: SW or NW
     C5: SE or NE
     C6: NW
     C7: NW or NE
     C8: NE
 Return the circle with center C and radius d.
 Notes:
 Regarding Step 1:
    The scale of a map is the ratio of a distance (a straight line) on
    the map to the corresponding air distance on the ground.  For maps
    covering larger areas, a map projection from a sphere (or
    ellipsoid) to the plane will introduce distortion, and the scale
    of the map is not constant.  Also, note that the real distance on
    the ground is taken along great circles, which may not correspond
    to straight lines on the map, depending on the projection used.
    Let us measure the (length) distortion of the map as the quotient
    between the maximal and the minimal scales on the map.  The
    distortion MUST be below 1.5.  (The minimum distortion is 1.0: if
    the region of the map is small, then the scale may be taken as a
    constant over the whole map).
 Regarding Step 3:
    SW is mnemonic for southwest, b for bottom, l for left (SW=(l,b)),
    etc., but the directions of the geodesic projection may be
    arbitrary, and thus SW may not be southwest of M, but it will be
    left and below M *on the map*.

Schulzrinne, et al. Standards Track [Page 14] RFC 6772 Geolocation Policy January 2013

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
 equals 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 [RFC5025]).
 <?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"
           xml:lang="en"
           label="Siemens Neuperlach site 'Legoland'"
           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. Standards Track [Page 15] RFC 6772 Geolocation Policy January 2013

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"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0">
   <rule id="BB56A19">
     <conditions>
       <gp:location-condition>
         <gp:location
           xml:lang="en"
           label="Sydney Opera House"
           profile="geodetic-condition">
           <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
             <gml:pos>-33.8570029378 151.2150070761</gml:pos>
             <gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
             </gs:radius>
           </gs:Circle>
         </gp:location>
       </gp:location-condition>
     </conditions>
     <transformations/>
   </rule>
 </ruleset>

Schulzrinne, et al. Standards Track [Page 16] RFC 6772 Geolocation Policy January 2013

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.
 <?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:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0">
   <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">
           <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-34.410649 150.87651</gml:pos>
              <gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
              </gs:radius>
           </gs:Circle>
         </gp:location>
       </gp:location-condition>
     </conditions>
     <actions/>
     <transformations/>
   </rule>
 </ruleset>

Schulzrinne, et al. Standards Track [Page 17] RFC 6772 Geolocation Policy January 2013

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.
 <?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 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 radius="500"/>
       </gp:provide-location>
     </transformations>
   </rule>
 </ruleset>

Schulzrinne, et al. Standards Track [Page 18] RFC 6772 Geolocation Policy January 2013

 The following rule describes the shorthand notation for making the
 current location of the Target available to Location Recipients
 without granularity reduction.
 <?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>

7.5. Location Obfuscation Example

 Suppose you want to obscure positions in the continental USA.
 Step 1:
    First, you choose a geodesic projection.  If you are measuring
    location as latitude and longitude, a natural choice is to take a
    rectangular projection.  One latitudinal degree corresponds to
    approximately 110.6 kilometers, while a good approximation of a
    longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where
    pi is approximately 3.1415, and M is the Earth's average
    meridional radius, approximately 6,367.5 km.  For instance, one
    longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km,
    while the formula given offers an estimation of 96.24, which is
    good enough for our purposes.
    We will set up a grid not only for the continental USA, but for
    the whole earth between latitudes 25 and 50 degrees, and thus will
    cover also the Mediterranean, South Europe, Japan, and the north
    of China.  As will be seen below, the grid distortion (for not too
    large grids in this region) is approx cos(25)/cos(50), which is
    1.4099.
    As origin of our grid, we choose the point at latitude 25 degrees
    and longitude 0 (Greenwich).  The latitude 25 degrees is chosen to
    be just south of Florida and thus south of the continental USA.
    (On the Southern Hemisphere, the origin should be north of the
    region to be covered; if the region crosses the Equator, the

Schulzrinne, et al. Standards Track [Page 19] RFC 6772 Geolocation Policy January 2013

    origin should be on the Equator.  In this way, it is guaranteed
    that the latitudinal degree has the largest distance at the
    latitude of the origin).
    At 25 degrees, one degree in east-west direction corresponds to
    approximately (pi/180)*M*cos(25) = 100.72 km.
    The same procedure, basically, produces grids for
  • 45 degrees south to 45 degrees north: Tropics and subtropics,

Africa, Australia

  • 25 to 50 degrees (both north or south): Continental United

States, Mediterranean, most of China; most of Chile and

       Argentina, New Zealand
  • 35 to 55 degrees (both north or south): Southern and Central

Europe

  • 45 to 60 degrees (both north or south): Central and Northern

Europe, Canada

  • 55 to 65 degrees (both north or south): most of Scandinavia
  • 60 to 70 degrees (both north or south): Alaska
    Since we do not want to change the grid system often (this would
    leak more information about obscured locations when they are
    repeatedly visited), the algorithm should prefer to use the grids
    discussed above, with origin at the Greenwich meridian and at
    latitudes o=0, o=25, o=35, o=45, 0=55, and o=60 degrees (north) or
    at latitudes o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the
    minus to indicate "south").
    Our choice for the continental USA is o=25.
    For locations close to the poles, a different projection should be
    used (not discussed here).
 Step 2:
    To construct the grid, we start with our chosen origin and place
    grid points at regular intervals along each of the axes (north-
    south and east-west) with a distance d between each.

Schulzrinne, et al. Standards Track [Page 20] RFC 6772 Geolocation Policy January 2013

    We will now construct a grid for a desired uncertainty of d =
    100km.  At our origin, 100 km correspond roughly to d1 = 100/
    100.72 = 0.993 degrees in an east-west direction and to d2 = 100/
    110.6 = 0.904 degrees in a north-south direction.
    The (i,j)-point in the grid (i and j are integers) has longitude
    d1*i and latitude 25+d2*j, measured in degrees.  More generally,
    if the grid has origin at coordinates (0,o), measured in degrees,
    the (i,j)-point in the grid has coordinates (longitude = d1*i,
    latitude = o+d2*j).  The grid has almost no distortion at the
    latitude of the origin, but it does as we go further away from it.
    The distance between two points in the grid at 25 degrees latitude
    is indeed approximately 100 km, but just above the Canadian
    border, on the 50th degree, it is 0.993*(pi/180)*M*cos(50) =
    70.92km.  Thus, the grid distortion is 100/70.92 = 1.41, which is
    acceptable (<1.5).  (In the north-south direction, the grid has
    roughly no distortion; the vertical distance between two
    neighboring grid points is approximately 100 km).
 Step 3:
    Now suppose you measure a position at M, with longitude -105 (the
    minus sign is used to denote 105 degrees *west*; without minus,
    the point is in China, 105 degrees east) and latitude 40 degrees
    (just north of Denver, CO).  The point M is 105 degrees west and
    15 degrees north of our origin (which has longitude 0 and latitude
    25).
    Let "floor" be the function that returns the largest integer
    smaller or equal to a floating point number.  To calculate SW, the
    closest point of the grid on the southwest of M=(m,n), we
    calculate
    i= floor(m/d1) = floor(-105/0.993) = -106
    j= floor(n-o/d2) = floor(15/0.904) = 16
    Those are the indexes of SW on the grid.  The coordinates of SW
    are then: (d1*i, 25+d2*j) = (-105.242, 39.467).
    Thus:
    l=d1*floor(m/d1) = -105.243
    r=l+d1 = -105.243+0.993 = -104.250
    b=o+d2*floor(n-o/d2) = 39.467

Schulzrinne, et al. Standards Track [Page 21] RFC 6772 Geolocation Policy January 2013

    t=b+d2 = 39.467+0.904 = 40.371
    These are the formulas for l, r, b, and t in the general case of
    Cartesian projections based on latitude and longitude.
 Step 4:
    Calculate x and y, the local coordinates of the point M in the
    small grid square that contains it.  This is easy:
    x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245
    y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590
 Step 5:
    First, compare x with p (0.2887) and 1-p (0.7113). x is smaller
    than p.  Therefore, only cases 1, 4, or 6 could hold.
    Also, compare y with p (0.2887) and 1-p (0.7113). y is between
    them: p <= y < q.  Thus, we must be in case 4.  To check, compare
    y (0.59) with x (0.245) and 1-x. y is larger than x and smaller
    than 1-x.  We are in case C4 (p <= y < q and x <= y and y < 1-x).
 Step 6:
    Now we choose either SW or NW as the center of the circle.
    The obscured location is the circle with radius 100 km and center
    in SW (coordinates: -105.243, 39.467) or NW (coordinates:
    -105.243, 40.371).

Schulzrinne, et al. Standards Track [Page 22] RFC 6772 Geolocation Policy January 2013

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:attribute name="radius" type="xs:integer"/>
         </xs:complexType>
     </xs:element>
 </xs:schema>

Schulzrinne, et al. Standards Track [Page 23] RFC 6772 Geolocation Policy January 2013

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 [RFC4745]).
 <?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"/>
         </xs:choice>
         <xs:attribute name="profile" type="xs:string"/>
         <xs:attribute name="label" type="xs:string"/>

Schulzrinne, et al. Standards Track [Page 24] RFC 6772 Geolocation Policy January 2013

         <xs:attribute ref="xml:lang" />
       </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>

10. XCAP Usage

 This 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 Application Unique ID
 (AUID) as those rules.  See [RFC5025] for a description of the XCAP
 usage in context with presence authorization rules.

Schulzrinne, et al. Standards Track [Page 25] RFC 6772 Geolocation Policy January 2013

10.1. Application Unique ID

 XCAP requires application usages to define a unique Application
 Unique 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 Media Type

 XCAP requires application usages to define the MIME media 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
 found beneath that point to guide authorization policy.

10.8. Resource Interdependencies

 This application usage does not define additional resource
 interdependencies.

Schulzrinne, et al. Standards Track [Page 26] RFC 6772 Geolocation Policy January 2013

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.

11. IANA Considerations

 There are several IANA considerations associated with this
 specification.

11.1. Geolocation Policy XML Schema Registration

 This section registers an XML schema in the IETF XML Registry as per
 the guidelines in [RFC3688].
 URI:  urn:ietf:params:xml:schema:geolocation-policy
 Registrant Contact:  IETF Geopriv Working Group (geopriv@ietf.org),
    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

 This section registers a new XML namespace in the IETF XML Registry
 as per the guidelines in [RFC3688].
 URI:  urn:ietf:params:xml:ns:geolocation-policy
 Registrant Contact:  IETF Geopriv Working Group (geopriv@ietf.org),
    Hannes Tschofenig (hannes.tschofenig@nsn.com).

Schulzrinne, et al. Standards Track [Page 27] RFC 6772 Geolocation Policy January 2013

 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>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="http://www.rfc-editor.org/rfc/rfc6772.txt">
    RFC 6772</a>.</p>
 </body>
 </html>
 END

11.3. Geolocation Policy Location Profile Registry

 This document creates a registry of location profile names for the
 Geolocation Policy framework.  Profile names are XML tokens.  This
 registry will operate in accordance with RFC 5226 [RFC5226],
 Specification Required.
 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

 This section registers an XML schema in the IETF XML Registry as per
 the guidelines in [RFC3688].
 URI:  urn:ietf:params:xml:schema:basic-location-profiles
 Registrant Contact:  IETF Geopriv Working Group (geopriv@ietf.org),
    Hannes Tschofenig (hannes.tschofenig@nsn.com).

Schulzrinne, et al. Standards Track [Page 28] RFC 6772 Geolocation Policy January 2013

 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

 This section registers a new XML namespace in the IETF XML Registry
 as per the guidelines in [RFC3688].
 URI:  urn:ietf:params:xml:ns:basic-location-profiles
 Registrant Contact:  IETF Geopriv Working Group (geopriv@ietf.org),
    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="http://www.rfc-editor.org/rfc/rfc6772.txt">
    RFC 6772</a>.</p>
 </body>
 </html>
 END

11.6. XCAP Application Usage ID

 This section registers an XCAP Application Unique ID (AUID) in the
 "XML-XCAP Application Unique IDs" registry according to the IANA
 procedures defined in [RFC4825].
 Name of the AUID: geolocation-policy

Schulzrinne, et al. Standards Track [Page 29] RFC 6772 Geolocation Policy January 2013

 Description: Geolocation privacy rules are documents that describe
 the permissions that a Target has granted to Location Recipients that
 access information about his/her geographic location.

12. Internationalization Considerations

 The policies described in this document are mostly meant for machine-
 to-machine communications; as such, many of its elements are tokens
 not meant for direct human consumption.  If these tokens are
 presented to the end user, some localization may need to occur.  The
 policies are, however, supposed to be created with the help of
 humans, and some of the elements and attributes are subject to
 internationalization considerations.  The content of the <label>
 element is meant to be provided by a human (the Rule Maker) and also
 displayed to a human.  Furthermore, the location condition element
 (<location-condition>, using the civic location profile, see
 Section 4.2) and the <set-note-well> element (see Section 6.3) may
 contain non-US-ASCII letters.
 The geolocation policies utilize XML, and all XML processors are
 required to understand UTF-8 and UTF-16 encodings.  Therefore, all
 entities processing these policies MUST understand UTF-8- and UTF-16-
 encoded XML.  Additionally, geolocation policy-aware entities MUST
 NOT encode XML with encodings other than UTF-8 or UTF-16.

13. Security Considerations

13.1. Introduction

 This document aims to allow users to prevent unauthorized access to
 location information and to restrict access to information dependent
 on the location of the Target, using location-based conditions.  This
 is accomplished using authorization policies.  This work builds on a
 series of other documents: security requirements are described in
 [RFC6280] and a discussion of generic security threats is available
 with [RFC3694].  Aspects of combining permissions in cases of
 multiple occurrence are addressed in [RFC4745].
 In addition to the authorization policies, mechanisms for obfuscating
 location information are described.  A theoretical treatment of
 location obfuscation is provided in [DUCKHAM05] and in [IFIP07].
 [DUCKHAM05] provides the foundation, and [IFIP07] illustrates three
 different types of location obfuscation by enlarging the radius, by
 shifting the center, and by reducing the radius.  The algorithm in
 Section 6.5.2 for geodetic location information obfuscation uses
 these techniques.

Schulzrinne, et al. Standards Track [Page 30] RFC 6772 Geolocation Policy January 2013

 The requirements for protecting privacy-sensitive location
 information vary.  The two obfuscation algorithms in this document
 provide a basis for protecting against unauthorized disclosure of
 location information, but they have limitations.  Application and
 user requirements vary widely; therefore, an extension mechanism is
 support for defining and using different algorithms.

13.2. Obfuscation

 Whenever location information is returned to a Location Recipient, it
 contains the location of the Target.  This is also true when location
 is obfuscated, i.e., the Location Server does not lie about the
 Target's location but instead hides it within a larger location
 shape.  Even without the Target's movement, there is a danger that
 information will be revealed over time.  While the Target's location
 is not revealed within a particular region of the grid, the size of
 that returned region matters as well as the precise location of the
 Target within that region.  Returning location shapes that are
 randomly computed will over time reveal more and more information
 about the Target.
 Consider Figure 1, which shows three ellipses, a dotted area in the
 middle, and the Target's true location marked as 'x'.  The ellipses
 illustrate the location shapes as received by a potential Location
 Recipient over time for requests of a Target's location information.
 Collecting information about the returned location information over
 time allows the Location Recipient to narrow the potential location
 of the Target down to the dotted area in the center of the graph.
 For this purpose, the algorithm described in Section 6.5.2 uses a
 grid that ensures the same location information is reported while the
 Target remains in the same geographical area.
                 ,-----.
         ,----,-'.      `-.
      ,-'    /    `-.      \
    ,'      / _...._ `.     \
   /       ,-'......`._\     :
  ;       /|...........\:    |
  |      / :.....x......+    ;
  :     |   \...........;|  /
   \    |    \........./ | /
    `.  \     `-.....,' ,''
      '-.\       `-----'|
         ``.-----'    ,'
            `._    _,'
               `'''
                Figure 1: Obfuscation: A Static Target

Schulzrinne, et al. Standards Track [Page 31] RFC 6772 Geolocation Policy January 2013

 An obscuring method that returns different results for consecutive
 requests can be exploited by recipients wishing to use this property.
 Rate limiting the generation of new obscured locations or providing
 the same obscured location to recipients for the same location might
 limit the information that can be obtained.  Note, however, that
 providing a new obscured location based on a change in location
 provides some information to recipients when they observe a change in
 location.
 When the Target is moving, then the location transformations reveal
 information when switching from one privacy region to another one.
 For example, when a transformation indicates that civic location is
 provided at a 'building' level of granularity, floor levels, room
 numbers, and other details normally internal to a building would be
 hidden.  However, when the Target moves from one building to the next
 one, then the movement would still be recognizable as the disclosed
 location information would be reflected by the new civic location
 information indicating the new building.  With additional knowledge
 about building entrances and floor plans, it would be possible to
 learn additional information.

13.3. Algorithm Limitations

 The algorithm presented in Section 6.5.2 has some issues where
 information is leaked: when moving, when switching from one privacy
 region to another one, and also when the user regularly visits the
 same location.
 The first issue arises if the algorithm provides different location
 information (privacy region) only when the previous one becomes
 inapplicable.  The algorithm discloses new information the moment
 that the Target is on the border of the old privacy region.
 Another issue arises if the algorithm produces the different values
 for the same location that is repeatedly visited.  Suppose a user
 goes home every night.  If the reported obfuscated locations are all
 randomly chosen, an analysis can reveal the home location with high
 precision.
 In addition to these concerns, the combination of an obscured
 location with public geographic information (highways, lakes,
 mountains, cities, etc.) may yield much more precise location
 information than is desired.  But even without it, just observing
 movements, once or multiple times, any obscuring algorithm can leak
 information about velocities or positions.  Suppose a user wants to
 disclose location information with a radius of r.  The privacy
 region, a circle with that radius, has an area of A = pi * r^2.  An
 adversary, observing the movements, will deduce that the target is

Schulzrinne, et al. Standards Track [Page 32] RFC 6772 Geolocation Policy January 2013

 visiting, was visiting, or regularly visits, a region of size A1,
 smaller than A.  The ratio A1/A should be, even in the worst case,
 larger than a fixed known number, in order that the user can predict
 the worst-case information leakage.  The choices of Section 6.5.2 are
 such that this maximum leakage can be established: by any statistical
 procedures, without using external information (highways, etc., as
 discussed above), the quotient A1/A is larger than 0.13 (= 1/(5*1.5)
 ).  Thus, for instance, when choosing a provided location of size
 1000 km^2, he will be leaking, in worst case, the location within a
 region of size 130 km^2.

13.4. Usability

 There is the risk that end users are specifying their location-based
 policies in such a way that very small changes in location yields a
 significantly different level of information disclosure.  For
 example, a user might want to set authorization policies differently
 when they are in a specific geographical area (e.g., at home, in the
 office).  Location might be the only factor in the policy that
 triggers a very different action and transformation to be executed.
 The accuracy of location information is not always sufficient to
 unequivocally determine whether a location is within a specific
 boundary [GEOPRIV-UNCERTAINTY].  In some situations, uncertainty in
 location information could produce unexpected results for end users.
 Providing adequate user feedback about potential errors arising from
 these limitation can help prevent unintentional information leakage.
 Users might create policies that are nonsensical.  To avoid such
 cases, the software used to create the authorization policies should
 perform consistency checks, and when authorization policies are
 uploaded to the policy servers, then further checks can be performed.
 When XCAP is used to upload authorization policies, then built-in
 features of XCAP can be utilized to convey error messages back to the
 user about an error condition.  Section 8.2.5 of [RFC4825] indicates
 that some degree of application-specific checking is provided when
 authorization policies are added, modified, or deleted.  The XCAP
 protocol may return a 409 response with a response that may contain a
 detailed conflict report containing the <constraint-failure> element.
 A human-readable description of the problem can be indicated in the
 'phrase' attribute of that element.

13.5. Limitations of Obscuring Locations

 Location-obscuring attempts to remove information about the location
 of a Target.  The effectiveness of location obscuring is determined
 by how much uncertainty a Location Recipient has about the location
 of the Target.  A location-obscuring algorithm is effective if the

Schulzrinne, et al. Standards Track [Page 33] RFC 6772 Geolocation Policy January 2013

 Location Recipient cannot recover a location with better uncertainty
 than the obscuring algorithm was instructed to add.
 Effective location obscuring is difficult.  The amount of information
 that can be recovered by a determined and resourceful Location
 Recipient can be considerably more than is immediately apparent.  A
 concise summary of the challenges is included in [DUCKHAM10].
 A Location Recipient in possession of external information about the
 Target or geographical area that is reported can make assumptions or
 guesses aided by that information to recover more accurate location
 information.  This is true even when a single location is reported,
 but it is especially true when multiple locations are reported for
 the same Target over time.
 Furthermore, a Location Recipient that attempts to recover past
 locations for a Target can use later-reported locations to further
 refine any recovered location.  A location-obscuring algorithm
 typically does not have any information about the future location of
 the Target.
 The degree to which location information can be effectively degraded
 by an obscuring algorithm depends on the information that is used by
 the obscuring algorithm.  If the information available to the
 obscuring algorithm is both more extensive and more effectively
 employed than the information available to the Location Recipient,
 then location obscuring might be effective.
 Obscured locations can still serve a purpose where a Location
 Recipient is willing to respect privacy.  A privacy-respecting
 Location Recipient can choose to interpret the existence of
 uncertainty as a request from a Rule Maker to not recover location.
 Location obscuring is unlikely to be effective against a more
 determined or resourceful adversary.  Withholding location
 information entirely is perhaps the most effective method of ensuring
 that it is not recovered.
 As a final caution, we note that omitted data also conveys some
 information.  Selective withholding of information reveals that there
 is something worth hiding.  That information might be used to reveal
 something of the information that is being withheld.  For example, if
 location is only obscured around a user's home and office, then the
 lack of location for that user and the current time will likely mean
 that the user is at home at night and in the office during the day,
 defeating the purpose of the controls.

Schulzrinne, et al. Standards Track [Page 34] RFC 6772 Geolocation Policy January 2013

14. References

14.1. Normative References

 [GML]      OpenGIS, "OpenGIS Geography Markup Language (GML)
            Implementation Specification, Version 3.1.1,
            OGC 03-105r1", July 2004,
            <http://portal.opengeospatial.org/files/
            ?artifact_id=4700>.
 [NIMA.TR8350.2-3e]
            "Department of Defense (DoD) World Geodetic System 1984
            (WGS 84), Third Edition", NIMA TR8350.2, January 2000.
 [OGC-06-103r4]
            OpenGIS, "OpenGIS Implementation Specification for
            Geographic  information - Simple feature access - Part 1:
            Common architecture", May 2011,
            <http://www.opengeospatial.org/standards/sfa?>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.
 [RFC4745]  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.
 [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
            Format for Presence Information Data Format Location
            Object (PIDF-LO)", RFC 5139, February 2008.
 [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
            Presence Information Data Format Location Object (PIDF-LO)
            Usage Clarification, Considerations, and Recommendations",
            RFC 5491, March 2009.

14.2. Informative References

 [DUCKHAM05]
            Duckham, M. and L. Kulik, "A Formal Model of Obfuscation
            and Negotiation for Location Privacy", In Proc. of the 3rd
            International Conference PERVASIVE 2005, Munich, Germany,
            May 2005.

Schulzrinne, et al. Standards Track [Page 35] RFC 6772 Geolocation Policy January 2013

 [DUCKHAM10]
            Duckham, M., "Moving Forward: Location Privacy and
            Location Awareness", In Proc. 3rd ACM SIGSPATIAL Workshop
            on Security and Privacy in GIS and LBS (SPRINGL), ACM,
            November 2010.
 [GEO-SHAPE]
            Thomson, M., "Geodetic Shapes for the Representation of
            Uncertainty in PIDF-LO", Work in Progress, December 2006.
 [GEOPRIV-UNCERTAINTY]
            Thomson, M. and J. Winterbottom, "Representation of
            Uncertainty and Confidence in PIDF-LO", Work in Progress,
            March 2012.
 [IFIP07]   Ardagna, C., Cremonini, M., Damiani, E., De Capitani di
            Vimercati, S., and P. Samarati, "Location Privacy
            Protection through Obfuscation-Based Techniques",
            Proceedings of the 21st Annual IFIP WG 11.3 Working
            Conference on Data and Applications Security, Redondo
            Beach, CA, USA, July 2007.
 [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
            Locators", RFC 2392, August 1998.
 [RFC2778]  Day, M., Rosenberg, J., and H. Sugano, "A Model for
            Presence and Instant Messaging", RFC 2778, February 2000.
 [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
            "Threat Analysis of the Geopriv Protocol", RFC 3694,
            February 2004.
 [RFC4079]  Peterson, J., "A Presence Architecture for the
            Distribution of GEOPRIV Location Objects", RFC 4079,
            July 2005.
 [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
            Format", RFC 4119, December 2005.
 [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
            Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
 [RFC5025]  Rosenberg, J., "Presence Authorization Rules", RFC 5025,
            December 2007.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

Schulzrinne, et al. Standards Track [Page 36] RFC 6772 Geolocation Policy January 2013

 [RFC6280]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
            Tschofenig, H., and H. Schulzrinne, "An Architecture for
            Location and Location Privacy in Internet Applications",
            BCP 160, RFC 6280, July 2011.

Schulzrinne, et al. Standards Track [Page 37] RFC 6772 Geolocation Policy January 2013

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>, and 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.  Richard Barnes gave a detailed
 review in February 2008.
 This document uses text from "Geodetic Shapes for the Representation
 of Uncertainty in PIDF-LO" [GEO-SHAPE], authored by Martin Thomson.
 We would like to thank Matt Lepinski and Richard Barnes for their
 comments regarding the geodetic location transformation procedure.
 Richard provided us with a detailed text proposal.
 Robert Sparks, and Warren Kumari deserve thanks for their input on
 the location obfuscation discussion.  Robert implemented various
 versions of the algorithm in the graphical language "Processing" and
 thereby helped us tremendously to understand problems with the
 previously illustrated algorithm.
 We would like to thank Dan Romascanu, Yoshiko Chong, and Jari
 Urpalainen for their last call comments.
 Finally, we would like to thank the following individuals for their
 feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko,
 Lisa Dusseault, Eric Gray, Sam Hartman, Russ Housley, Cullen
 Jennings, Chris Newman, Jon Peterson, Tim Polk, Carl Reed, and Brian
 Rosen.
 Although John Morris is currently employed by the U.S. Government, he
 participated in the development of this document in his personal
 capacity, and the views expressed in the document may not reflect
 those of his employer.

Schulzrinne, et al. Standards Track [Page 38] RFC 6772 Geolocation Policy January 2013

Appendix B. Pseudocode

 This section provides an informal description for the algorithm
 described in 6.5.2 and 7.5 as pseudocode.  In addition to the
 algorithm, it randomly chooses among equidistant landmarks based on
 the previous location.
 Constants
   P = sqrt(3)/6  //  approx 0.2887
   q = 1 - p      //  approx 0.7113
 Parameters
   prob:  real  // prob is a parameter in the range
         //  0.5 <= prob <=1
         // recommended is a value for prob between 0.7 and 0.9
         // the default of prob is 0.8
 Inputs
   M = (m,n) : real * real
         // M is a pair of reals: m and n
         // m is the longitude and n the latitude,
         // respectively, of the measured location
         // The values are given as real numbers, in the
         // range: -180 < m <= 180; -90 < n < 90
         // minus values for longitude m correspond to "West"
         // minus values for latitude n correspond to "South"
   radius : integer // the 'radius' or uncertainty,
         // measured in meters
   prev-M = (prev-m1, prev-n1): real * real
         // the *previously* provided location, if available
         // prev-m1 is the longitude and
         // prev-n1 the latitude, respectively
   o : real
   // this is the reference latitude for the geodesic projection
   // The value of 'o' is chosen according to the table below.
   // The area you want to project MUST be included in
   // between a minimal latitude and a maximal latitude
   // given by the two first columns of the table.
   // (Otherwise the transformation is not available).

Schulzrinne, et al. Standards Track [Page 39] RFC 6772 Geolocation Policy January 2013

   //    +------+------+--------------------------+-------+
   //    | min  | max  |                          |       |
   //    | lat  | lat  |        Examples          |  o    |
   //    +------+------+--------------------------+-------+
   //    |      |      | Tropics and subtropics   |       |
   //    | -45  |  45  | Africa                   |  0    |
   //    |      |      | Australia                |       |
   //    +------+------+--------------------------+-------+
   //    |      |      | Continental US           |       |
   //    |  25  |  50  | Mediterranean            |   25  |
   //    |      |      | most of China            |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    |  35  |  55  | Southern and Central     |   35  |
   //    |      |      |      Europe              |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    |  45  |  60  | Central and Northern     |   45  |
   //    |      |      |       Europe             |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    |  55  |  65  | most of Scandinavia      |   55  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    |  60  |  70  |                          |   60  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+
   //    |      |      | most of                  |       |
   //    | -50  | -25  |    Chile and Argentina   |  -50  |
   //    |      |      | New Zealand              |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    | -35  | -55  |                          |  -35  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    | -45  | -60  |                          |  -45  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    | -55  | -65  |                          |  -55  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+
   //    |      |      |                          |       |
   //    | -60  | -70  |                          |  -60  |
   //    |      |      |                          |       |
   //    +------+------+--------------------------+-------+

Schulzrinne, et al. Standards Track [Page 40] RFC 6772 Geolocation Policy January 2013

 Outputs
   M1 = (m1,n1) : real * real // longitude and latitude,
         // respectively, of the provided location
 Local Variables
   d, d1, d2, l, r, b, t, x, y: real
   SW, SE, NW, NE: real * real
      // pairs of real numbers, interpreted as coordinates
      // longitude and latitude, respectively
   temp : Integer[1..8]
 Function
   choose(Ma, Mb: real * real): real * real;
      // This function chooses either Ma or Mb
      // depending on the parameter 'prob'
      // and on prev-M1, the previous value of M1:
      // If prev-M1 == Ma choose Ma with probability 'prob'
      // If prev-M1 == Mb choose Mb with probability 'prob'
      // Else choose Ma or Mb with probability 1/2
   Begin
   rand:= Random[0,1];
      // a real random number between 0 and 1
   If     prev-M1 == Ma Then
          If rand < prob Then choose := Ma;
                         Else choose := Mb;  EndIf
   Elseif prev-M1 == Mb Then
          If rand < prob Then choose := Mb;
                         Else choose := Ma;  EndIf
   Else
          If rand < 0.5  Then choose := Ma;
                         Else choose := Mb;  EndIf
   End // Function choose
 Main  // main procedure
   Begin
   d := radius/1000;  // uncertainty, measured in km
   d1:= (d * 180) / (pi*M*cos(o));
   d2:= d / 110.6;
   l := d1*floor(m/d1)
         // "floor"  returns the largest integer
         // smaller or equal to a floating point number
   r := l+d1;

Schulzrinne, et al. Standards Track [Page 41] RFC 6772 Geolocation Policy January 2013

   b := o+d2*floor(n-o/d2);
   t := b+d2;
   x := (m-l)/(r-l);
   y := (n-b)/(t-b);
   SW := (l,b);
   SE := (r,b);
   NW := (l,t);
   NE := (r,t);
   If     x < p and y < p      Then M1 := SW;
   Elseif x < p and q <= y     Then M1 := NW;
   Elseif q <= x and y < p     Then M1 := SE;
   Elseif q <= x and q <= y    Then M1 := NE;
   Elseif p <= x and x < q and y < x  and y < 1-x
          Then M1 := choose(SW,SE);
   Elseif p <= y and y < q and x <= y and y < 1-x
          Then M1 := choose(SW,NW);
   Elseif p <= y and y < q and y < x  and 1-x <= y
          Then M1 := choose(SE,NE);
   Elseif p <= x and x < q and x <= y and 1-x <= y
          Then M1 := choose(NW,NE);
   Endif
   End //  Main

Schulzrinne, et al. Standards Track [Page 42] RFC 6772 Geolocation Policy January 2013

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
 Linnoitustie 6
 Espoo  02600
 Finland
 Phone: +358 (50) 4871445
 EMail: Hannes.Tschofenig@gmx.net
 URI:   http://www.tschofenig.priv.at
 Jorge R. Cuellar
 Siemens
 Otto-Hahn-Ring 6
 Munich, Bavaria  81739
 Germany
 EMail: Jorge.Cuellar@siemens.com
 James Polk
 Cisco
 2200 East President George Bush Turnpike
 Richardson, Texas  75082
 USA
 Phone: +1 817-271-3552
 EMail: jmpolk@cisco.com
 John B. Morris, Jr.
 EMail: ietf@jmorris.org

Schulzrinne, et al. Standards Track [Page 43] RFC 6772 Geolocation Policy January 2013

 Martin Thomson
 Microsoft
 3210 Porter Drive
 Palo Alto, CA  94304
 USA
 Phone: +1 650-353-1925
 EMail: martin.thomson@gmail.com

Schulzrinne, et al. Standards Track [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6772.txt · Last modified: 2013/01/10 20:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki