One document matched: draft-ietf-geopriv-policy-19.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4745 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml'>
<!ENTITY RFC4119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
<!ENTITY RFC4825 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml'>
<!ENTITY RFC5139 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml'>
<!ENTITY RFC4079 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4079.xml'>
<!ENTITY RFC2434 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY RFC5025 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml'>
<!ENTITY I-D.thomson-geopriv-geo-shape PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-geo-shape.xml'>
<!ENTITY I-D.thomson-geopriv-uncertainty PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml'>
<!ENTITY I-D.ietf-geopriv-pdif-lo-profile PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml'>
]>
<rfc category="std" ipr="trust200811" docName="draft-ietf-geopriv-policy-19.txt">
<front>
<title abbrev="Geolocation Policy">Geolocation Policy: A Document Format for Expressing Privacy
Preferences for Location Information</title>
<author role="editor" initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<phone>+1 212 939 7042</phone>
<email>schulzrinne@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu/~hgs</uri>
</address>
</author>
<author role="editor" initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="J." surname="Morris" fullname="John B. Morris, Jr.">
<organization abbrev="CDT">Center for Democracy and Technology</organization>
<address>
<postal>
<street>1634 I Street NW, Suite 1100</street>
<city>Washington</city>
<region>DC</region>
<code>20006</code>
<country>USA</country>
</postal>
<email>jmorris@cdt.org</email>
<uri>http://www.cdt.org</uri>
</address>
</author>
<author initials="J." surname="Cuellar" fullname="Jorge R. Cuellar">
<organization abbrev="Siemens">Siemens</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Jorge.Cuellar@siemens.com</email>
</address>
</author>
<author initials="J." surname="Polk" fullname="James Polk">
<organization abbrev="Cisco">Cisco</organization>
<address>
<postal>
<street>2200 East President George Bush Turnpike</street>
<city>Richardson</city>
<region>Texas</region>
<code>75082</code>
<country>USA</country>
</postal>
<email>jmpolk@cisco.com</email>
</address>
</author>
<date year="2009"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Authorization Policy</keyword>
<keyword>Location Privacy</keyword>
<abstract>
<t>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 based on the current
location of the Target. Furthermore, it offers location-specific transformation elements to
reduce the granularity of the returned location information.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Location information needs to be protected against unauthorized access to preserve the
privacy of humans. In RFC 3693 <xref target="RFC3693"/>, 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. </t>
<t>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) <xref target="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, 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.</t>
<t>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.</t>
<t>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 <xref target="RFC3693"
/>. 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 <xref target="RFC4745"/>. 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.</t>
<t>This document does not describe the protocol used to convey location information from the
Location Server to the Location Recipient (i.e., the using protocol; see RFC 3693 <xref
target="RFC3693"/>). </t>
<t>This document extends the Common Policy framework defined in <xref target="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, 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.</t>
<t>The XML schema defined in <xref target="schema"/> 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.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>This document reuses the terminology of RFC 3693 <xref target="RFC3693"/>, 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:</t>
<t>
<list style="hanging">
<t hangText="Presentity or Target:">
<vspace blankLines="1"/>RFC 3693 <xref target="RFC3693"/> uses the term Target to
identify the object or person of which location information is required. The presence
model described in RFC 2778 <xref target="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.<vspace
blankLines="1"/>
</t>
<t hangText="Watcher or Location Recipient:">
<vspace blankLines="1"/>The receiver of location information is the Location Recipient
(LR) in the terminology of RFC 3693 <xref target="RFC3693"/>. 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.<vspace blankLines="1"/>
</t>
<t hangText="Authorization policy:">
<vspace blankLines="1"/>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. <vspace blankLines="1"/>
</t>
<t hangText="Permission:">
<vspace blankLines="1"/>The term permission refers to the action and transformation
components of a rule.</t>
</list>
</t>
<t>The term 'using protocol' is defined in <xref target="RFC3693"/> and refers to the protocol
that is used to request access to and to return privacy sensitive data items.</t>
<t>In this document we use the term Location Servers as the entities that evaluate the
geolocation authorization policies. The geolocation privacy architecture is, as motivated in
RFC 4079 <xref target="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.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Generic Processing">
<section title="Structure of Geolocation Authorization Documents">
<t> A geolocation authorization document is an XML document, formatted according to the
schema defined in <xref target="RFC4745"/>. Geolocation authorization documents inherit
the MIME type of common policy documents, application/auth-policy+xml. As described in
<xref target="RFC4745"/>, 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. </t>
</section>
<section anchor="rule-transport" title="Rule Transport">
<t>There are two ways how the authorization rules described in this document may be conveyed
between different parties:</t>
<t>
<list style="symbols">
<t>RFC 4119 <xref target="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. </t>
<t>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) <xref target="RFC4825"/>.</t>
</list>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="conditions" title="Location-specific Conditions">
<t>This section describes the location-specific conditions of a rule. The
<conditions> element contains zero, one or an unbounded number of
<location-condition> child element(s). Providing more than one
<location-condition> 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. </t>
<t>The <location> element has three attributes, namely 'profile', 'xml:lang' and
'label'. The 'profile' attribute allows to indicate the location profile that is included as
child elements in the <location> element and each 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, see <xref
target="geodetic-condition"/> and <xref target="civic-condition"/>. The 'label' attribute
allows a human readable description to be added to each lt;location> element. The
'xml:lang' attribute contains a language tag providing further information for rendering of
the content of the 'label' attribute.</t>
<t>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. </t>
<section anchor="geodetic-condition" title="Geodetic Location Condition Profile">
<t>The geodetic location profile is identified by the token 'geodetic-condition'. Rule
Makers use this profile by placing a <xref target="GML">GML</xref> <Circle>
element within the <location> element (as described in Section 5.2.3 of
<xref target="I-D.ietf-geopriv-pdif-lo-profile"/>). </t>
<t>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
location. Note that the Target's actual location might be represented by any of the
location shapes described in <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>. If the
geodetic location of the Target is unknown then the <location> element
containing the information for the geodetic location profile evaluates to FALSE. </t>
<t>Implementations are REQUIRED to support the following coordinate reference system based
on WGS 84 <xref target="NIMA.TR8350.2-3e"/> based on the European Petroleum Survey Group
(EPSG) Geodetic Parameter Dataset (as formalized by the Open Geospatial Consortium (OGC)): </t>
<t>
<list style="hanging">
<t hangText="2D:">WGS 84 (latitude, longitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.</t>
</list>
</t>
<t>A CRS MUST be specified using the above URN notation only, implementations do not need to
support user-defined CRSs. </t>
<t>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. </t>
</section>
<section anchor="civic-condition" title="Civic Location Condition Profile">
<t>The civic location profile is identified by the token 'civic-condition'. Rule Makers use
this profile by placing a <civicAddress> element, defined in <xref
target="RFC5139"/>, within the <location> element.</t>
<t> 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 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 a bit-by-bit comparison. </t>
<t>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. In general, it is
RECOMMENDED behavior for a LS not to apply a translation from geodetic location to civic
location (i.e., geocode the location). </t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Actions">
<t>This document does not define location-specific actions. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="transformations" title="Transformations">
<t>This document defines several elements that allow Rule Makers to specify transformations
that <list style="symbols">
<t>reduce the accuracy of the returned location information, and </t>
<t>set the basic authorization policies carried inside the PIDF-LO.</t>
</list>
</t>
<section title="Set Retransmission-Allowed">
<t>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. </t>
<t>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. </t>
<t>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.</t>
</section>
<section title="Set Retention-Expiry">
<t>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.</t>
<t> The value provided with the <set-retention-expiry> element indicates
seconds and these seconds are added to the current date.</t>
<t>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.</t>
</section>
<section anchor="notewell" title="Set Note-Well">
<t>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.</t>
<t> 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.</t>
<t>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.</t>
</section>
<section title="Keep Ruleset Reference">
<t>This transformation allows to influence whether the <external-ruleset>
element in the PIDF-LO carries the extended authorization rules defined in <xref
target="RFC4745"/>. The data type of the <keep-rule-reference> element is
Boolean. </t>
<t> 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 to an
external rule set. The reference to the ruleset is removed and no rules are carried as
MIME bodies (in case of CID URIs). </t>
<t>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.</t>
</section>
<section title="Provide Location">
<t>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:<vspace blankLines="1"/>
<list style="symbols">
<t hangText="civic-transformation:">If the <provide-location> element has
a <provide-civic> child element then civic location information is
disclosed as described in <xref target="civic-transformation"/>, subject to
availability.<vspace blankLines="1"/></t>
<t hangText="geodetic-transformation:">If the <provide-location> element
has a <provide-geo> child element then geodetic location information is
disclosed as described in <xref target="geodetic-transformation"/>, subject to
availability.<vspace blankLines="1"/></t>
</list>
</t>
<t> 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.</t>
<t> 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.</t>
<section anchor="civic-transformation" title="Civic Location Profile">
<t>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 <xref target="RFC5139"/>.
Each level includes all elements included by the lower levels.</t>
<t>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.</t>
<t>
<figure>
<artwork><![CDATA[
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
{}
]]></artwork>
</figure>
</t>
<!-- <t>The following mapping is used for computing the combining permissions.
The symbolic names are used in authorization policies</t>
<t>
<figure>
<artwork><![CDATA[
none (value = 0, and default value)
country (value = 10)
region (value = 20)
city (value = 30)
building (value = 40)
full (value = 50)
]]></artwork>
</figure>
</t>
<t>The label "none" has the meaning of "do not provide civic information".</t>
-->
<t>The default value is "none".</t>
<t>The schema of the <provide-civic> element is defined in <xref
target="profile-schema"/>.</t>
</section>
<section anchor="geodetic-transformation" title="Geodetic Location Profile">
<t>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.</t>
<t>The schema of the <provide-geo> element is defined in <xref
target="profile-schema"/>.</t>
<t> For each rule in the policy specification containing a <provide-geo>
element, the LS chooses a circle with a radius F given by the 'radius' attribute of the
<provide-geo> element. The center of the circle is chosen randomly, under
the constraint that the circle MUST contain the Target's location, which may be a point
or another location shape. In response to queries matching this rule, the LS MUST return
a shape containing this circle; while the returned shape may change from one query to
another, the chosen circle remains constant as long as the Target's location (whether a
point or a region) remains completely within the circle. An LS may, for example, store
the location of the center or compute it based on a hash function that includes the
target's identity. If the Target's location moves within the chosen circle, the LS MAY
choose a new random center point, but when the Target's location moves outside the
chosen circle, the LS MUST choose a new random center point. </t>
<t>The above-described procedure aims to satisfy the following design goals: <list
style="numbers">
<t> The circle returned must contain the actual location of the Target. </t>
<t>In general, no point in the circle must be more likely than others to contain the
Target. </t>
<t>Repeated queries must not reveal the likely location of the Target. </t>
</list>
</t>
</section>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="example" title="Examples">
<t>This section provides a few examples for authorization rules using the extensions defined
in this document. </t>
<section title="Rule Example with Civic Location Condition">
<t>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'.</t>
<t>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 <xref
target="RFC5025"/>). </t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Rule Example with Geodetic Location Condition">
<t>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. </t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Rule Example with Civic and Geodetic Location Condition">
<t>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. </t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Rule Example with Location-based Transformations">
<t>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.</t>
<t>
<figure>
<artwork><![CDATA[
<?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 radius="500"/>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
]]></artwork>
</figure>
</t>
<t>The following rule describes the short-hand notation for making the current location of
the Target available to Location Recipients without granularity reduction. </t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="profile-schema" title="XML Schema for Basic Location Profiles">
<t>This section defines the location profiles used as child elements of the transformation
element.</t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="schema" title="XML Schema for Geolocation Policy">
<t>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 <xref
target="RFC4745"/>).</t>
<t>
<figure>
<artwork><![CDATA[
<?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="label" type="gp:labelType"
minOccurs="0" maxOccurs="1"/>
<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: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="labelType">
<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>
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="XCAP Usage">
<t> 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 <xref target="RFC5025"/> for a description of the XCAP
usage in context with presence authorization rules. </t>
<section title="Application Unique ID">
<t>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 <xref target="iana"/>. </t>
</section>
<section title="XML Schema">
<t>XCAP requires application usages to define a schema for their documents. The schema for
geolocation authorization documents is described in <xref target="schema"/>. </t>
</section>
<section title="Default Namespace">
<t> XCAP requires application usages to define the default namespace for their documents.
The default namespace is urn:ietf:params:xml:ns:geolocation-policy. </t>
</section>
<section title="MIME Type">
<t> 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. </t>
</section>
<section title="Validation Constraints">
<t>This specification does not define additional constraints.</t>
</section>
<section title="Data Semantics">
<t>This document discusses the semantics of a geolocation privacy authorization.</t>
</section>
<section title="Naming Conventions">
<t> 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. </t>
</section>
<section title="Resource Interdependencies">
<t>This application usage does not define additional resource interdependencies. </t>
</section>
<section title="Authorization Policies">
<t>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. </t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="iana" title="IANA Considerations">
<t>There are several IANA considerations associated with this specification. </t>
<section title="Geolocation Policy XML Schema Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geolocation-policy</t>
<t hangText="Registrant Contact:">IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">The XML schema to be registered is contained in <xref target="schema"
/>. Its first line is <figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
]]></artwork>
</figure> and its last line is<figure>
<artwork><![CDATA[
</xs:schema>
]]></artwork>
</figure></t>
</list>
</t>
</section>
<section title="Geolocation Policy Namespace Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:geolocation-policy</t>
<t hangText="Registrant Contact:">IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section anchor="profile-registry" title="Geolocation Policy Location Profile Registry">
<t>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 <xref target="RFC2434">RFC 2434</xref>, Standards Action.</t>
<t>This document defines the following profile names:</t>
<t>
<list style="hanging">
<t hangText="geodetic-condition:"> Defined in <xref target="geodetic-condition"/>.</t>
<t hangText="civic-condition:"> Defined in <xref target="civic-condition"/>.</t>
<t hangText="geodetic-transformation:"> Defined in <xref
target="geodetic-transformation"/>.</t>
<t hangText="civic-transformation:"> Defined in <xref target="civic-transformation"
/>.</t>
</list>
</t>
</section>
<section title="Basic Location Profile XML Schema Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:basic-location-profiles</t>
<t hangText="Registrant Contact:">IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">The XML schema to be registered is contained in <xref
target="profile-schema"/>. Its first line is <figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
]]></artwork>
</figure> and its last line is<figure>
<artwork><![CDATA[
</xs:schema>
]]></artwork>
</figure></t>
</list>
</t>
</section>
<section title="Basic Location Profile Namespace Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:basic-location-profiles</t>
<t hangText="Registrant Contact:">IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XCAP Application Usage ID">
<t>This section registers an XCAP Application Usage ID (AUID) according to the IANA
procedures defined in <xref target="RFC4825"/>.</t>
<t> Name of the AUID: geolocation-policy </t>
<t> 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. </t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Internationalization Considerations">
<t> 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 (using the civic
location profile, see <xref target="civic-condition"/>) and the
<set-note-well> element (see <xref target="notewell"/>) may contain non-US-ASCII letters. </t>
<t> The geolocation polices utilize XML and all XML processors are required to understand
UTF-8 and UTF-16 encodings, and 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. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Security Considerations">
<t>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 <xref target="RFC3693"/> and
a discussion of generic security threats is available with <xref target="RFC3694"/>. Aspects
of combining permissions in cases of multiple occurrence are treated in <xref
target="RFC4745"/>). </t>
<t> 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. Hence, room
numbers, floors etc. 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 streets it would be
possible to learn a certain amont of information. It is therefore important to ensure that
selected privacy regions are not chosen too small when mobility is a concern and that a
random number to is added to the position of the Target, with an absolute value of half the
privacy region. The latter aspect is only applicable for geodetic information or when
geodetic information is translated to civic information by the Location Server. </t>
<t>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. Unfortunately, location may come from different sources and these sources might
produce civic or geodetic location information potentially requiring transcoding. This
process may lead to a loss of precision and other errors. Furthermore, with the process of
location determination there are many factors that introduce errors into the measurements.
Some details on how these errors are expressed in the form of uncertainty can be found at
<xref target="I-D.thomson-geopriv-uncertainty"/>. Users specifying authorization policies
might experience unanticipated results from the policy execution. As such, users might need
to get educated about the limitations of location technologies to avoid information leakage.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
</reference> &RFC5139; &RFC4745; <reference anchor="GML">
<front>
<title>OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.00,
OGC 02 023r4</title>
<author fullname="OpenGIS" initials="" surname="OpenGIS">
<organization/>
</author>
<date year="2003" month="January"/>
</front>
<seriesInfo value="http://www.opengeospatial.org/docs/02-023r4.pdf" name=""/>
<format type="PDF" target="http://www.opengeospatial.org/docs/02-023r4.pdf"/>
</reference>
<reference anchor="NIMA.TR8350.2-3e">
<front>
<title>US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic
System 1984 (WGS 84), Third Edition, NIMA TR8350.2</title>
<author fullname="OpenGIS" initials="" surname="OpenGIS">
<organization/>
</author>
<date year="2000" month="January"/>
</front>
<seriesInfo value=" " name=""/>
<format type=" " target=" "/>
</reference> &I-D.ietf-geopriv-pdif-lo-profile; </references>
<references title="Informative References"> &RFC4825; &RFC4119; <reference
anchor="RFC2778">
<front>
<title>A Model for Presence and Instant Messaging</title>
<author initials="M." surname="Day" fullname="Mark Day">
<organization>SightPath, Inc.</organization>
<address>
<postal>
<street>135 Beaver Street</street>
<city>Waltham</city>
<region>MA</region>
<code>02452</code>
<country>US</country>
</postal>
<email>mday@alum.mit.edu</email>
</address>
</author>
<author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg">
<organization>dynamicsoft</organization>
<address>
<postal>
<street>200 Executive Drive</street>
<street>Suite 120</street>
<city>West Orange</city>
<region>NJ</region>
<code>07046</code>
<country>US</country>
</postal>
<email>jdrosen@dynamicsoft.com</email>
</address>
</author>
<author initials="H." surname="Sugano" fullname="Hiroyasu Sugano">
<organization>Fujitsu Laboratories Ltd.</organization>
<address>
<postal>
<street>64 Nishiwaki</street>
<street>Ohkubo-cho</street>
<city>Akashi</city>
<region/>
<code>674-8555</code>
<country>JP</country>
</postal>
<email>suga@flab.fujitsu.co.jp</email>
</address>
</author>
<date year="2000" month="February"/>
<abstract>
<t>This document defines an abstract model for a presence and instant messaging system.
It defines the various entities involved, defines terminology, and outlines the
services provided by the system. The goal is to provide a common vocabulary for
further work on requirements for protocols and markup for presence and instant
messaging.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2778"/>
<format type="TXT" octets="35153" target="ftp://ftp.isi.edu/in-notes/rfc2778.txt"/>
</reference> &RFC4079; &RFC5025; &I-D.thomson-geopriv-geo-shape; &RFC2434;
&I-D.thomson-geopriv-uncertainty; <reference anchor="RFC3694">
<front>
<title>Threat Analysis of the Geopriv Protocol</title>
<author fullname="M. Danley" initials="M." surname="Danley">
<organization/>
</author>
<author fullname="D. Mulligan" initials="D." surname="Mulligan">
<organization/>
</author>
<author fullname="J. Morris" initials="J." surname="Morris">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<date year="2004" month="February"/>
</front>
<seriesInfo value="3694" name="RFC"/>
<format octets="44364" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3694.txt"/>
</reference>
<reference anchor="RFC3693">
<front>
<title>Geopriv Requirements</title>
<author fullname="J. Cuellar" initials="J." surname="Cuellar">
<organization/>
</author>
<author fullname="J. Morris" initials="J." surname="Morris">
<organization/>
</author>
<author fullname="D. Mulligan" initials="D." surname="Mulligan">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="J. Polk" initials="J." surname="Polk">
<organization/>
</author>
<date year="2004" month="February"/>
</front>
<seriesInfo value="3693" name="RFC"/>
<format octets="68881" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3693.txt"/>
</reference>
</references>
<section title="Acknowledgments">
<t>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.</t>
<t> 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.</t>
<t>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.</t>
<t>This document uses text from <xref target="I-D.thomson-geopriv-geo-shape"/>. Therefore, we
would like to thank Martin Thomson for his work in <xref
target="I-D.thomson-geopriv-geo-shape"/>. We would also like to thank Martin Thomson, Matt
Lepinski and Richard Barnes for their comments regarding the geodetic location
transformation procedure. Richard provided us with a detailed text proposal. </t>
<t>We would like to thank Dan Romascanu, Yoshiko Chong and Jari Urpalainen for their last call
comments. </t>
<t>Finally, we would like to thank the following individuals for their feedback as part of the
IESG, GenArt, and SecDir review: Jari Arkko, Eric Gray, Russ Housley, Carl Reed, Martin
Thomson, Lisa Dusseault, Chris Newman, Jon Peterson, Sam Hartman, Cullen Jennings, Tim Polk,
and Brian Rosen.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:05:46 |