< draft-ietf-geopriv-policy-25.txt		draft-ietf-geopriv-policy-26.txt >
	GEOPRIV H. Schulzrinne, Ed.		GEOPRIV H. Schulzrinne, Ed.
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig, Ed.		Intended status: Standards Track H. Tschofenig, Ed.
	Expires: April 16, 2012 Nokia Siemens Networks		Expires: December 7, 2012 Nokia Siemens Networks
	J. Cuellar		J. Cuellar
	Siemens		Siemens
	J. Polk		J. Polk
	Cisco		Cisco
	J. Morris		J. Morris
	M. Thomson		M. Thomson
	Commscope		Microsoft
	October 14, 2011		June 5, 2012
	Geolocation Policy: A Document Format for Expressing Privacy Preferences		Geolocation Policy: A Document Format for Expressing Privacy Preferences
	for Location Information		for Location Information
	draft-ietf-geopriv-policy-25.txt		draft-ietf-geopriv-policy-26
	Abstract		Abstract
	This document defines an authorization policy language for		This document defines an authorization policy language for
	controlling access to location information. It extends the Common		controlling access to location information. It extends the Common
	Policy authorization framework to provide location-specific access		Policy authorization framework to provide location-specific access
	control. More specifically, this document defines condition elements		control. More specifically, this document defines condition elements
	specific to location information in order to restrict access based on		specific to location information in order to restrict access based on
	the current location of the Target.		the current location of the Target.
	Furthermore, this document defines two algorithms for reducing the		Furthermore, this document defines two algorithms for reducing the
	granularity of returned location information. The first algorithm is		granularity of returned location information. The first algorithm is
	defined for usage with civic location information while the other one		defined for usage with civic location information while the other one
	applies to geodetic location information. Both algorithms come with		applies to geodetic location information. Both algorithms come with
	limitations, i.e. they provide location obfuscation under certain		limitations. There are circumstances where the amount of location
	conditions and may therefore not be appropriate for all application		obfuscation provided is less than what is desired. These algorithms
	domains.		might not be appropriate for all application domains.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 16, 2012.		This Internet-Draft will expire on December 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	7.2. Rule Example with Geodetic Location Condition . . . . . . 19		7.2. Rule Example with Geodetic Location Condition . . . . . . 19
	7.3. Rule Example with Civic and Geodetic Location Condition . 19		7.3. Rule Example with Civic and Geodetic Location Condition . 19
	7.4. Rule Example with Location-based Transformations . . . . . 20		7.4. Rule Example with Location-based Transformations . . . . . 20
	7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 22		7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 22
	8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 26		8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 26
	9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 27		9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 27
	10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 29		10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 29
	10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 29		10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 29		10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 29
	10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 29		10.4. MIME Media Type . . . . . . . . . . . . . . . . . . . . . 29
	10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 29		10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 29
	10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 29		10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 29
	10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 29		10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 29
	10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 30		10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 30
	10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 30		10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 30
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	11.1. Geolocation Policy XML Schema Registration . . . . . . . . 31		11.1. Geolocation Policy XML Schema Registration . . . . . . . . 31
	11.2. Geolocation Policy Namespace Registration . . . . . . . . 31		11.2. Geolocation Policy Namespace Registration . . . . . . . . 31
	11.3. Geolocation Policy Location Profile Registry . . . . . . . 32		11.3. Geolocation Policy Location Profile Registry . . . . . . . 32
	11.4. Basic Location Profile XML Schema Registration . . . . . . 32		11.4. Basic Location Profile XML Schema Registration . . . . . . 32
	11.5. Basic Location Profile Namespace Registration . . . . . . 33		11.5. Basic Location Profile Namespace Registration . . . . . . 33
	11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33		11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 34
	12. Internationalization Considerations . . . . . . . . . . . . . 35		12. Internationalization Considerations . . . . . . . . . . . . . 35
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 36		13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36		13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36
	13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36		13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36
	13.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38		13.3. Algorithm Limitations . . . . . . . . . . . . . . . . . . 38
	13.4. Location Obscuring Limitations . . . . . . . . . . . . . . 39		13.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40		13.5. Location Obscuring Limitations . . . . . . . . . . . . . . 39
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 40		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	14.2. Informative References . . . . . . . . . . . . . . . . . . 40		14.1. Normative References . . . . . . . . . . . . . . . . . . . 41
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42		14.2. Informative References . . . . . . . . . . . . . . . . . . 41
	Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 43		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47		Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 44
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
	1. Introduction		1. Introduction
	Location information needs to be protected against unauthorized		Location information needs to be protected against unauthorized
	access to preserve the privacy of humans. In RFC 3693 [RFC3693], a		access to preserve the privacy of humans. In RFC 6280 [RFC6280], a
	protocol-independent model for access to geographic information is		protocol-independent model for access to geographic information is
	defined. The model includes a Location Generator (LG) that		defined. The model includes a Location Generator (LG) that
	determines location information, a Location Server (LS) that		determines location information, a Location Server (LS) that
	authorizes access to location information, a Location Recipient (LR)		authorizes access to location information, a Location Recipient (LR)
	that requests and receives location information, and a Rule Maker		that requests and receives location information, and a Rule Maker
	(RM) that writes authorization policies. An authorization policy is		(RM) that writes authorization policies. An authorization policy is
	a set of rules that regulates an entity's activities with respect to		a set of rules that regulates an entity's activities with respect to
	privacy-sensitive information, such as location information.		privacy-sensitive information, such as location information.
	The data object containing location information in the context of		The data object containing location information in the context of
	this document is referred to as a Location Object (LO). The basic		this document is referred to as a Location Object (LO). The basic
	rule set defined in the Presence Information Data Format Location		rule set defined in the Presence Information Data Format Location
	Object (PIDF-LO) [RFC4119] can restrict how long the Location		Object (PIDF-LO) [RFC4119] can restrict how long the Location
	Recipient is allowed to retain the information, and it can prohibit		Recipient is allowed to retain the information, and it can prohibit
	further distribution. It also contains a reference to an enhanced		further distribution. It also contains a reference to an enhanced
	rule set and a human readable privacy policy. The basic rule set,		rule set and a human readable privacy policy. The basic rule set
	however, does not allow to control access to location information		does not access to location information. This document describes an
	based on specific Location Recipients. This document describes an
	enhanced rule set that provides richer constraints on the		enhanced rule set that provides richer constraints on the
	distribution of LOs.		distribution of LOs.
	The rule set allows the entity that uses the rules defined in this		The enhanced rule set allows the entity that uses the rules defined
	document to restrict the retention and to enforce access restrictions		in this document to restrict the retention and to enforce access
	on location data, including prohibiting any dissemination to		restrictions on location data, including prohibiting any
	particular individuals, during particular times or when the Target is		dissemination to particular individuals, during particular times or
	located in a specific region. The RM can also stipulate that only		when the Target is located in a specific region. The RM can also
	certain parts of the Location Object are to be distributed to		stipulate that only certain parts of the Location Object are to be
	recipients or that the resolution of parts of the Location Object is		distributed to recipients or that the resolution is reduced for parts
	reduced.		of the Location Object.
	The typical sequence of operations is as follows. A Location Server		In the typical sequence of operations, a Location Server receives a
	receives a query for location information for a particular Target.		query for location information for a particular Target. The
	The requestor's identity will likely be revealed as part of this		requestor's identity will likely be revealed as part of this request
	request for location information. The authenticated identity of the		for location information. The authenticated identity of the Location
	Location Recipient, together with other information provided with the		Recipient, together with other information provided with the request
	request or generally available to the server, is then used for		or generally available to the server, is then used for searching
	searching through the rule set. If more than one rule matches the		through the rule set. If more than one rule matches the condition
	condition element, then the combined permission is evaluated		element, then the combined permission is evaluated according to the
	according to the description in Section 10 of [RFC4745]. The result		description in Section 10 of [RFC4745]. The result of the rule
	of the rule evalation is applied to the location information,		evalation is applied to the location information, yielding a possibly
	yielding a possibly modified Location Object that is delivered to the		modified Location Object that is delivered to the Location Recipient.
	Location Recipient.
	This document does not describe the protocol used to convey location		This document does not describe the protocol used to convey location
	information from the Location Server to the Location Recipient.		information from the Location Server to the Location Recipient.
	This document extends the Common Policy framework defined in		This document extends the Common Policy framework defined in
	[RFC4745]. That document provides an abstract framework for		[RFC4745]. That document provides an abstract framework for
	expressing authorization rules. As specified there, each such rule		expressing authorization rules. As specified there, each such rule
	consists of conditions, actions and transformations. Conditions		consists of conditions, actions and transformations. Conditions
	determine under which circumstances the entity executing the rules,		determine under which circumstances the entity executing the rules,
	for example a Location Server, is permitted to apply actions and		such as a Location Server, is permitted to apply actions and
	transformations. Transformations regulate in a location information		transformations. Transformations regulate in a location information
	context how a Location Server modifies the information elements that		context how a Location Server modifies the information elements that
	are returned to the requestor, for example, by reducing the		are returned to the requestor by, for example, reducing the
	granularity of returned location information.		granularity of returned location information.
	This document defines two algorithms for reducing the granularity of		This document defines two algorithms for reducing the granularity of
	returned location information. The first algorithm is defined for		returned location information. The first algorithm is defined for
	usage with civic location information (see Section 6.5.1) while the		usage with civic location information (see Section 6.5.1) while the
	other one applies to geodetic location information (see		other one applies to geodetic location information (see
	Section 6.5.2). Both algorithms come with limitations, i.e. they		Section 6.5.2). Both algorithms come with limitations, i.e. they
	provide location obfuscation under certain conditions and may		provide location obfuscation under certain conditions and may
	therefore not be appropriate for all application domains. These		therefore not be appropriate for all application domains. These
	limitations are documented within the security consideration section		limitations are documented within the security consideration section
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	by introducing new child elements to the condition and transformation		by introducing new child elements to the condition and transformation
	elements. This document does not define child elements for the		elements. This document does not define child elements for the
	action part of a rule.		action part of a rule.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document reuses the terminology of RFC 3693 [RFC3693], such as		This document reuses the terminology of RFC 6280 [RFC6280], such as
	Location Server (LS), Location Recipient (LR), Rule Maker (RM),		Location Server (LS), Location Recipient (LR), Rule Maker (RM),
	Target, Location Generator (LG) and Location Object (LO). This		Target, Location Generator (LG) and Location Object (LO). This
	document uses the following terminology:		document uses the following terminology:
	Presentity or Target:		Presentity or Target:
	RFC 3693 [RFC3693] uses the term Target to identify the object or		RFC 6280 [RFC6280] uses the term Target to identify the object or
	person of which location information is required. The presence		person of which location information is required. The presence
	model described in RFC 2778 [RFC2778] uses the term presentity to		model described in RFC 2778 [RFC2778] uses the term presentity to
	describe the entity that provides presence information to a		describe the entity that provides presence information to a
	presence service. A Presentity in a presence system is a Target		presence service. A Presentity in a presence system is a Target
	in a location information system.		in a location information system.
	Watcher or Location Recipient:		Watcher or Location Recipient:
	The receiver of location information is the Location Recipient		The receiver of location information is the Location Recipient
	(LR) in the terminology of RFC 3693 [RFC3693]. A watcher in a		(LR) in the terminology of RFC 6280 [RFC6280]. A watcher in a
	presence system, i.e., an entity that requests presence		presence system, i.e., an entity that requests presence
	information about a presentity, is a Location Recipient in a		information about a presentity, is a Location Recipient in a
	location information system.		location information system.
	Authorization policy:		Authorization policy:
	An authorization policy is given by a rule set. A rule set		An authorization policy is given by a rule set. A rule set
	contains an unordered list of (policy) rules. Each rule has a		contains an unordered list of (policy) rules. Each rule has a
	condition, an action and a transformation component.		condition, an action and a transformation component.
	Permission:		Permission:
	The term permission refers to the action and transformation		The term "permission" refers to the action and transformation
	components of a rule.		components of a rule.
	In this document we use the term Location Servers as the entities		In this document we use the term Location Servers as the entities
	that evaluate the geolocation authorization policies. The		that evaluate the geolocation authorization policies. The
	geolocation privacy architecture is, as motivated in RFC 4079		geolocation privacy architecture is, as described in RFC 4079
	[RFC4079], aligned with the presence architecture and a Presence		[RFC4079], aligned with the presence architecture and a Presence
	Server is therefore an entity that distributes location information		Server is therefore an entity that distributes location information
	along with other presence-specific XML data elements.		along with other presence-specific XML data elements.
	3. Generic Processing		3. Generic Processing
	3.1. Structure of Geolocation Authorization Documents		3.1. Structure of Geolocation Authorization Documents
	A geolocation authorization document is an XML document, formatted		A geolocation authorization document is an XML document, formatted
	according to the schema defined in [RFC4745]. Geolocation		according to the schema defined in [RFC4745]. Geolocation
	authorization documents inherit the MIME type of common policy		authorization documents inherit the media type of common policy
	documents, application/auth-policy+xml. As described in [RFC4745],		documents, application/auth-policy+xml. As described in [RFC4745],
	this document is composed of rules which contain three parts -		this document is composed of rules which contain three parts -
	conditions, actions, and transformations. Each action or		conditions, actions, and transformations. Each action or
	transformation, which is also called a permission, has the property		transformation, which is also called a permission, has the property
	of being a positive grant of information to the Location Recipient.		of being a positive grant of information to the Location Recipient.
	As a result, there is a well-defined mechanism for combining actions		As a result, there is a well-defined mechanism for combining actions
	and transformations obtained from several sources. This mechanism is		and transformations obtained from several sources. This mechanism is
	privacy safe, since the lack of any action or transformation can only		privacy safe, since the lack of any action or transformation can only
	result in less information being presented to a Location Recipient.		result in less information being presented to a Location Recipient.
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 47 ¶
	Section 5.2.3 of [RFC5491]).		Section 5.2.3 of [RFC5491]).
	The <location> element containing the information for the geodetic		The <location> element containing the information for the geodetic
	location profile evaluates to TRUE if the current location of the		location profile evaluates to TRUE if the current location of the
	Target is within the described location. Note that the Target's		Target is within the described location. Note that the Target's
	actual location might be represented by any of the location shapes		actual location might be represented by any of the location shapes
	described in [RFC5491]. If the geodetic location of the Target is		described in [RFC5491]. If the geodetic location of the Target is
	unknown then the <location> element containing the information for		unknown then the <location> element containing the information for
	the geodetic location profile evaluates to FALSE.		the geodetic location profile evaluates to FALSE.
	Implementations are REQUIRED to support the following coordinate		Implementations MUST support the WGS 84 [NIMA.TR8350.2-3e] coordinate
	reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the		reference system using the formal identifier from the European
	European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as		Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as
	formalized by the Open Geospatial Consortium (OGC)):		formalized by the Open Geospatial Consortium (OGC)):
	2D: WGS 84 (latitude, longitude), as identified by the URN		2D: WGS 84 (latitude, longitude), as identified by the URN
	"urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.		"urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS.
	A CRS MUST be specified using the above URN notation only,		A CRS MUST be specified using the above URN notation only,
	implementations do not need to support user-defined CRSs.		implementations do not need to support user-defined CRSs.
	Implementations MUST specify the CRS using the "srsName" attribute on		Implementations MUST specify the CRS using the "srsName" attribute on
	the outermost geometry element. The CRS MUST NOT be changed for any		the outermost geometry element. The CRS MUST NOT be changed for any
	skipping to change at page 12, line 38 ¶		skipping to change at page 12, line 38 ¶
	unchanged or, if the PIDF-LO is created for the first time, then the		unchanged or, if the PIDF-LO is created for the first time, then the
	value MUST be set to FALSE.		value MUST be set to FALSE.
	6.2. Set Retention-Expiry		6.2. Set Retention-Expiry
	This transformation asks the LS to change or set the value of the		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		<retention-expiry> element in the PIDF-LO. The data type of the
	<set-retention-expiry> element is an integer.		<set-retention-expiry> element is an integer.
	The value provided with the <set-retention-expiry> element indicates		The value provided with the <set-retention-expiry> element indicates
	seconds and these seconds are added to the current date.		seconds and these seconds are added to the time that the LS provides
			location.
	If the <set-retention-expiry> element is absent then the value of the		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		<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		the PIDF-LO is created for the first time, then the value MUST be set
	to the current date.		to the current date.
	6.3. Set Note-Well		6.3. Set Note-Well
	This transformation asks the LS to change or set the value of the		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-		<note-well> element in the PIDF-LO. The data type of the <set-note-
	skipping to change at page 13, line 45 ¶		skipping to change at page 13, line 46 ¶
	information. This form of location granularity reduction is also		information. This form of location granularity reduction is also
	called 'obfuscation' and is defined in [duckham05] as		called 'obfuscation' and is defined in [duckham05] as
	"the means of deliberately degrading the quality of information		"the means of deliberately degrading the quality of information
	about an individual's location in order to protect that		about an individual's location in order to protect that
	individual's location privacy."		individual's location privacy."
	Location obscuring presents a number of technical challenges. The		Location obscuring presents a number of technical challenges. The
	algorithms provided in this document are provided as examples only.		algorithms provided in this document are provided as examples only.
	A discussion of the technical constraints on location obscuring is		A discussion of the technical constraints on location obscuring is
	included in Section 13.4.		included in Section 13.5.
	The functionality of location granularity reduction depends on the		The functionality of location granularity reduction depends on the
	type of location provided as input. This document defines two		type of location provided as input. This document defines two
	profiles for reduction, namely:		profiles for reduction, namely:
	o If the <provide-location> element has a <provide-civic> child		o If the <provide-location> element has a <provide-civic> child
	element then civic location information is disclosed as described		element then civic location information is disclosed as described
	in Section 6.5.1, subject to availability.		in Section 6.5.1, subject to availability.
	o If the <provide-location> element has a <provide-geo> child		o If the <provide-location> element has a <provide-geo> child
	skipping to change at page 15, line 49 ¶		skipping to change at page 15, line 49 ¶
	This profile uses the token 'geodetic-transformation' and refers only		This profile uses the token 'geodetic-transformation' and refers only
	to the Coordinate Reference System (CRS) WGS 84		to the Coordinate Reference System (CRS) WGS 84
	(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic		(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic
	location transformations to be specified by means of the <provide-		location transformations to be specified by means of the <provide-
	geo> element that may restrict the returned geodetic location		geo> element that may restrict the returned geodetic location
	information based on the value provided in the 'radius' attribute.		information based on the value provided in the 'radius' attribute.
	The value of the 'radius' attribute expresses the radius in meters.		The value of the 'radius' attribute expresses the radius in meters.
	The schema of the <provide-geo> element is defined in Section 8.		The schema of the <provide-geo> element is defined in Section 8.
	The algorithm proceeds in 6 steps.The first two steps are independent		The algorithm proceeds in 6 steps. The first two steps are
	of the measured position to be obscured. Those two steps should be		independent of the measured position to be obscured. Those two steps
	run only once or rather seldom (for every region and desired		should be run only once or rather seldom (for every region and
	uncertainty). The steps are:		desired uncertainty). The steps are:
	1. Choose a geodesic projection with Cartesian coordinates and a		1. Choose a geodesic projection with Cartesian coordinates and a
	surface you want to cover. The maximal distortion of the map may		surface you want to cover. The maximal distortion of the map may
	not be too much (see notes below).		not be too much (see notes below).
	2. Given uncertainty "d", choose a grid of so called "landmarks" at		2. Given uncertainty "d", choose a grid of so called "landmarks" at
	a distance (maximal) d of each other.		a distance (maximal) d of each other.
	3. Given a measured location M=(m,n) in the surface, calculate its 4		3. Given a measured location M=(m,n) in the surface, calculate its 4
	closest landmarks on the grid, with coordinates: SW = (l,b),		closest landmarks on the grid, with coordinates: SW = (l,b),
	skipping to change at page 17, line 27 ¶		skipping to change at page 18, line 5 ¶
	the region of the map is small, then the scale may be taken as a		the region of the map is small, then the scale may be taken as a
	constant over the whole map).		constant over the whole map).
	Regarding Step3:		Regarding Step3:
	SW is mnemonic for south-west, b for bottom, l for left		SW is mnemonic for south-west, b for bottom, l for left
	(SW=(l,b)), etc, but the directions of the geodesic projection may		(SW=(l,b)), etc, but the directions of the geodesic projection may
	be arbitrary, and thus SW may be not south-west of M but it will		be arbitrary, and thus SW may be not south-west of M but it will
	be left and below M *on the map*.		be left and below M *on the map*.
	This algorithm is applied to the known location every time it
	changes. Movement between the defined grid areas triggers a change
	in the location that is reported, which could reveal significantly
	more about the location than desired.
	7. Examples		7. Examples
	This section provides a few examples for authorization rules using		This section provides a few examples for authorization rules using
	the extensions defined in this document.		the extensions defined in this document.
	7.1. Rule Example with Civic Location Condition		7.1. Rule Example with Civic Location Condition
	This example illustrates a single rule that employs the civic		This example illustrates a single rule that employs the civic
	location condition. It matches if the current location of the Target		location condition. It matches if the current location of the Target
	equal the content of the child elements of the <location> element.		equal the content of the child elements of the <location> element.
	skipping to change at page 29, line 32 ¶		skipping to change at page 29, line 32 ¶
	XCAP requires application usages to define a schema for their		XCAP requires application usages to define a schema for their
	documents. The schema for geolocation authorization documents is		documents. The schema for geolocation authorization documents is
	described in Section 9.		described in Section 9.
	10.3. Default Namespace		10.3. Default Namespace
	XCAP requires application usages to define the default namespace for		XCAP requires application usages to define the default namespace for
	their documents. The default namespace is		their documents. The default namespace is
	urn:ietf:params:xml:ns:geolocation-policy.		urn:ietf:params:xml:ns:geolocation-policy.
	10.4. MIME Type		10.4. MIME Media Type
	XCAP requires application usages to defined the MIME type for		XCAP requires application usages to defined the MIME media type for
	documents they carry. Geolocation privacy authorization documents		documents they carry. Geolocation privacy authorization documents
	inherit the MIME type of common policy documents, application/		inherit the MIME type of common policy documents, application/
	auth-policy+xml.		auth-policy+xml.
	10.5. Validation Constraints		10.5. Validation Constraints
	This specification does not define additional constraints.		This specification does not define additional constraints.
	10.6. Data Semantics		10.6. Data Semantics
	skipping to change at page 31, line 12 ¶		skipping to change at page 31, line 12 ¶
	documents that they do not own, but the establishment and indication		documents that they do not own, but the establishment and indication
	of such policies is outside the scope of this document.		of such policies is outside the scope of this document.
	11. IANA Considerations		11. IANA Considerations
	There are several IANA considerations associated with this		There are several IANA considerations associated with this
	specification.		specification.
	11.1. Geolocation Policy XML Schema Registration		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		URI: urn:ietf:params:xml:schema:geolocation-policy
	Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig		Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org),
	(hannes.tschofenig@nsn.com).		Hannes Tschofenig (hannes.tschofenig@nsn.com).
	XML: The XML schema to be registered is contained in Section 9. Its		XML: The XML schema to be registered is contained in Section 9. Its
	first line is		first line is
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	and its last line is		and its last line is
	</xs:schema>		</xs:schema>
	11.2. Geolocation Policy Namespace Registration		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		URI: urn:ietf:params:xml:ns:geolocation-policy
	Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig		Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org),
	(hannes.tschofenig@nsn.com).		Hannes Tschofenig (hannes.tschofenig@nsn.com).
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	skipping to change at page 32, line 28 ¶		skipping to change at page 32, line 28 ¶
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	11.3. Geolocation Policy Location Profile Registry		11.3. Geolocation Policy Location Profile Registry
	This document seeks to create a registry of location profile names		This document creates a registry of location profile names for the
	for the Geolocation Policy framework. Profile names are XML tokens.		Geolocation Policy framework. Profile names are XML tokens. This
	This registry will operate in accordance with RFC 2434 [RFC2434],		registry will operate in accordance with RFC 5226 [RFC5226],
	Standards Action.		Specification Required.
	This document defines the following profile names:		This document defines the following profile names:
	geodetic-condition: Defined in Section 4.1.		geodetic-condition: Defined in Section 4.1.
	civic-condition: Defined in Section 4.2.		civic-condition: Defined in Section 4.2.
	geodetic-transformation: Defined in Section 6.5.2.		geodetic-transformation: Defined in Section 6.5.2.
	civic-transformation: Defined in Section 6.5.1.		civic-transformation: Defined in Section 6.5.1.
	11.4. Basic Location Profile XML Schema Registration		11.4. Basic Location Profile XML Schema Registration
	URI: urn:ietf:params:xml:schema:basic-location-profiles		This section registers an XML schema in the IETF XML Registry as per
			the guidelines in [RFC3688].
	Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig		URI: urn:ietf:params:xml:schema:basic-location-profiles
	(hannes.tschofenig@nsn.com).		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 8. Its		XML: The XML schema to be registered is contained in Section 8. Its
	first line is		first line is
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	and its last line is		and its last line is
	</xs:schema>		</xs:schema>
	11.5. Basic Location Profile Namespace Registration		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		URI: urn:ietf:params:xml:ns:basic-location-profiles
	Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig		Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org),
	(hannes.tschofenig@nsn.com).		Hannes Tschofenig (hannes.tschofenig@nsn.com).
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	skipping to change at page 33, line 46 ¶		skipping to change at page 34, line 7 ¶
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	11.6. XCAP Application Usage ID		11.6. XCAP Application Usage ID
	This section registers an XCAP Application Usage ID (AUID) according		This section registers an XCAP Application Unique ID (AUID) in the
	to the IANA procedures defined in [RFC4825].		"XML-XCAP Application Unique IDs" registry according to the IANA
			procedures defined in [RFC4825].
	Name of the AUID: geolocation-policy		Name of the AUID: geolocation-policy
	Description: Geolocation privacy rules are documents that describe		Description: Geolocation privacy rules are documents that describe
	the permissions that a Target has granted to Location Recipients that		the permissions that a Target has granted to Location Recipients that
	access information about his/her geographic location.		access information about his/her geographic location.
	12. Internationalization Considerations		12. Internationalization Considerations
	The policies described in this document are mostly meant for machine-		The policies described in this document are mostly meant for machine-
	skipping to change at page 36, line 14 ¶		skipping to change at page 36, line 14 ¶
	13. Security Considerations		13. Security Considerations
	13.1. Introduction		13.1. Introduction
	This document aims to allow users to prevent unauthorized access to		This document aims to allow users to prevent unauthorized access to
	location information and to restrict access to information dependent		location information and to restrict access to information dependent
	on geolocation (via location based conditions). This is accomplished		on geolocation (via location based conditions). This is accomplished
	through the usage of authorization policies. This work builds on a		through the usage of authorization policies. This work builds on a
	series of other documents: Security requirements are described in		series of other documents: Security requirements are described in
	[RFC3693] and a discussion of generic security threats is available		[RFC6280] and a discussion of generic security threats is available
	with [RFC3694]. Aspects of combining permissions in cases of		with [RFC3694]. Aspects of combining permissions in cases of
	multiple occurrence are treated in [RFC4745]).		multiple occurrence are treated in [RFC4745].
	In addition to the authorization policies mechanisms for obfuscating		In addition to the authorization policies mechanisms for obfuscating
	location information are described. A theoretical treatment of		location information are described. A theoretical treatment of
	location obfuscation is provided in [duckham05] and in [ifip07].		location obfuscation is provided in [duckham05] and in [ifip07].
	[duckham05] provides the foundation and [ifip07] illustrates three		[duckham05] provides the foundation and [ifip07] illustrates three
	different types of location obfuscation by enlarging the radius, by		different types of location obfuscation by enlarging the radius, by
	shifting the center, and by reducing the radius. This algorithm for		shifting the center, and by reducing the radius. The algorithm in
	geodetic location information obfuscation makes use of these		Section 6.5.2 for geodetic location information obfuscation makes use
	techniques.		of these techniques.
	The requirements of location information with respect to privacy		The requirements of location information with respect to privacy
	protection vary. While the two obfuscation algorithm in this		protection vary. While the two obfuscation algorithm in this
	document provide a basis for protection they have limitations. There		document provide a basis for protection they have limitations. There
	are certainly applications that require a different level of		are certainly applications that require a different level of
	protection and for this purpose the ability to define and use		protection and for this purpose the ability to define and use
	additional algorithms has been envisioned. New algorithms can be		additional algorithms has been envisioned. New algorithms can be
	specified via the available extension mechanism.		specified via the available extension mechanism.
	13.2. Obfuscation		13.2. Obfuscation
	skipping to change at page 37, line 29 ¶		skipping to change at page 37, line 29 ¶
	: | \...........;| /		: | \...........;| /
	\ | \........./ | /		\ | \........./ | /
	`. \ `-.....,' ,''		`. \ `-.....,' ,''
	'-.\ `-----'|		'-.\ `-----'|
	``.-----' ,'		``.-----' ,'
	`._ _,'		`._ _,'
	`'''		`'''
	Figure 1: Obfuscation: A Static Target		Figure 1: Obfuscation: A Static Target
			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		When the Target is moving then the location transformations reveal
	information when switching from one privacy region to another one.		information when switching from one privacy region to another one.
	For example, when a transformation indicates that civic location is		For example, when a transformation indicates that civic location is
	provided at a 'building' level of granularity. Consequently, floor		provided at a 'building' level of granularity, floor levels, room
	levels, room numbers, etc. would be hidden. However, when the Target		numbers, and other details normally internal to a building would be
	moves from one building to the next one then the movement would still		hidden. However, when the Target moves from one building to the next
	be recognizable as the disclosed location information would be		one then the movement would still be recognizable as the disclosed
	reflected by the new civic location information indicating the new		location information would be reflected by the new civic location
	building. With additional knowledge about building entrances and		information indicating the new building. With additional knowledge
	floor plans it would be possible to learn additional amount of		about building entrances and floor plans it would be possible to
	information.		learn additional amount of information.
	The algorithm presented in Section 6.5.2 has some measures against		13.3. Algorithm Limitations
	leaking information when moving, switching from one privacy region to
	another one, and also when the user is visiting regularly the same		The algorithm presented in Section 6.5.2 has some issues where
	location. The first issue is the following: if you provide a		information is leaked: when moving, switching from one privacy region
	different location information (privacy region) only when the		to another one; and also when the user regularly visits the same
	previous one is not valid anymore, you will be disclosing the moment		location.
	where you are in a certain border (namely: leaving the previous
	privacy region). The second issue is the following: Suppose a user		The first issue arises if the algorithm provides a 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		goes home every night. If the reported obfuscated locations are all
	randomly different, an analysis will probably soon reveal the home		randomly different, an analysis will probably soon reveal the home
	location with high precision. Of course, the combination of an		location with high precision.
	obscured location with public geographic information (highways,
	lakes, mountains, cities, etc) may render a much precise location		In addition to these concerns, the combination of an obscured
			location with public geographic information (highways, lakes,
			mountains, cities, etc) may render a much precise location
	information than desired. But even without it, just observing		information than desired. But even without it, just observing
	movements, once or in a regular repetitive way, any obscuring		movements, once or in a regular repetitive way, any obscuring
	algorithm will leak information about velocities or positions.		algorithm will leak information about velocities or positions.
	Suppose a user wants to disclose location information with a radius		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		of r. The privacy region, a circle with that radius, has an area of
	A = pi * r^2. An opponent, observing the movements, will deduce that		A = pi * r^2. An opponent, observing the movements, will deduce that
	the information that the target is, was, or regularly visits, a		the information that the target is, was, or regularly visits, a
	region of size A1, smaller than A. The quotient of the sizes A1/A		region of size A1, smaller than A. The quotient of the sizes A1/A
	should be, even in the worst case, larger than a fixed known number,		should be, even in the worst case, larger than a fixed known number,
	in order that the user knows what is the maximal information leakage		in order that the user knows what is the maximal information leakage
	he has. The choices of 6.5.2 are such that this maximum leakage can		he has. The choices of Section 6.5.2 are such that this maximum
	be established: by any statistical procedures, without using		leakage can be established: by any statistical procedures, without
	geographic information (highways, etc. as discussed above), the		using external information (highways, etc. as discussed above), the
	quotient A1/A is larger than 0.13 (= 1/(5*1.5) ). Thus, for		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		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		will be leaking, in worst case, the location within a region of size
	130 km^2.		130 km^2.
	13.3. Usability		13.4. Usability
	There is the risk that end users are specifying their location-based		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		policies in such a way that very small changes in location yields a
	significantly different level of information disclosure. For		significantly different level of information disclosure. For
	example, a user might want to set authorization policies differently		example, a user might want to set authorization policies differently
	when they are in a specific geographical area (e.g., at home, in the		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		office). Location might be the only factor in the policy that
	triggers a very different action and transformation to be executed.		triggers a very different action and transformation to be executed.
	The accuracy of location information is not always sufficient to		The accuracy of location information is not always sufficient to
	unequivocally determine whether a location is within a specific		unequivocally determine whether a location is within a specific
	boundary [I-D.thomson-geopriv-uncertainty]. In some situations		boundary [I-D.thomson-geopriv-uncertainty]. In some situations
	uncertainty in location information could produce unexpected results		uncertainty in location information could produce unexpected results
	for end users. Providing adequate user feedback about potential		for end users. Providing adequate user feedback about potential
	errors arising from these limitation can help prevent unintentional		errors arising from these limitation can help prevent unintentional
	information leakage.		information leakage.
	Users might create policies that are non-sensical. To avoid such		Users might create policies that are non-sensical. To avoid such
	cases the software used to create the authorization policies should		cases the software used to create the authorization policies should
	skipping to change at page 39, line 8 ¶		skipping to change at page 39, line 27 ¶
	When XCAP is used to upload authorization policies then built-in		When XCAP is used to upload authorization policies then built-in
	features of XCAP can be utilized to convey error messages back to the		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		user about an error condition. Section 8.2.5 of [RFC4825] indicates
	that some degree of application specific checking is provided when		that some degree of application specific checking is provided when
	authorization policies are added, modified or deleted. The XCAP		authorization policies are added, modified or deleted. The XCAP
	protocol may return a 409 response with a response that may contain a		protocol may return a 409 response with a response that may contain a
	detailed conflict report containing the <constraint-failure> element.		detailed conflict report containing the <constraint-failure> element.
	A human readable description of the problem can be indicated in the		A human readable description of the problem can be indicated in the
	'phrase' attribute of that element.		'phrase' attribute of that element.
	13.4. Location Obscuring Limitations		13.5. Location Obscuring Limitations
	Location obscuring attempts to remove information about the location		Location obscuring attempts to remove information about the location
	of a Target. The effectiveness of location obscuring is determined		of a Target. The effectiveness of location obscuring is determined
	by how much uncertainty a Location Recipient has about the location		by how much uncertainty a Location Recipient has about the location
	of the Target. A location obscuring algorithm is effective if the		of the Target. A location obscuring algorithm is effective if the
	Location Recipient cannot recover a location with better uncertainty		Location Recipient cannot recover a location with better uncertainty
	than the obscuring algorithm was instructed to add.		than the obscuring algorithm was instructed to add.
	Effective location obscuring is difficult. The amount of information		Effective location obscuring is difficult. The amount of information
	that can be recovered by a determined and resourceful Location		that can be recovered by a determined and resourceful Location
	skipping to change at page 39, line 50 ¶		skipping to change at page 40, line 20 ¶
	then location obscuring might be effective.		then location obscuring might be effective.
	Obscured locations can still serve a purpose where a Location		Obscured locations can still serve a purpose where a Location
	Recipient is willing to respect privacy. A privacy-respecting		Recipient is willing to respect privacy. A privacy-respecting
	Location Recipient can choose to interpret the existence of		Location Recipient can choose to interpret the existence of
	uncertainty as a request from a Rule Maker to not recover location.		uncertainty as a request from a Rule Maker to not recover location.
	Location obscuring is unlikely to be effective against a more		Location obscuring is unlikely to be effective against a more
	determined or resourceful adversary. Withholding location		determined or resourceful adversary. Withholding location
	information entirely is perhaps the most effective method of ensuring		information entirely is perhaps the most effective method of ensuring
	that it is not recovered. However, a caution: omitted data also		that it is not recovered.
	conveys some information.
			A caution: 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.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[GML] OpenGIS, "OpenGIS Geography Markup Language (GML)		[GML] OpenGIS, "OpenGIS Geography Markup Language (GML)
	Implementation Specification, Version 3.00, OGC 02 023r4",		Implementation Specification, Version 3.00, OGC 02 023r4",
	http://www.opengeospatial.org/docs/02-023r4.pdf,		http://www.opengeospatial.org/docs/02-023r4.pdf,
	January 2003.		January 2003.
	[NIMA.TR8350.2-3e]		[NIMA.TR8350.2-3e]
	OpenGIS, "US National Imagery and Mapping Agency,		OpenGIS, "US National Imagery and Mapping Agency,
	"Department of Defense (DoD) World Geodetic System 1984		"Department of Defense (DoD) World Geodetic System 1984
	(WGS 84), Third Edition, NIMA TR8350.2", , January 2000.		(WGS 84), Third Edition, NIMA TR8350.2", , January 2000.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		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.,		[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
	Polk, J., and J. Rosenberg, "Common Policy: A Document		Polk, J., and J. Rosenberg, "Common Policy: A Document
	Format for Expressing Privacy Preferences", RFC 4745,		Format for Expressing Privacy Preferences", RFC 4745,
	February 2007.		February 2007.
	[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location		[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
	Format for Presence Information Data Format Location		Format for Presence Information Data Format Location
	Object (PIDF-LO)", RFC 5139, February 2008.		Object (PIDF-LO)", RFC 5139, February 2008.
	skipping to change at page 40, line 47 ¶		skipping to change at page 41, line 50 ¶
	[I-D.thomson-geopriv-geo-shape]		[I-D.thomson-geopriv-geo-shape]
	Thomson, M., "Geodetic Shapes for the Representation of		Thomson, M., "Geodetic Shapes for the Representation of
	Uncertainty in PIDF-LO",		Uncertainty in PIDF-LO",
	draft-thomson-geopriv-geo-shape-03 (work in progress),		draft-thomson-geopriv-geo-shape-03 (work in progress),
	December 2006.		December 2006.
	[I-D.thomson-geopriv-uncertainty]		[I-D.thomson-geopriv-uncertainty]
	Thomson, M. and J. Winterbottom, "Representation of		Thomson, M. and J. Winterbottom, "Representation of
	Uncertainty and Confidence in PIDF-LO",		Uncertainty and Confidence in PIDF-LO",
	draft-thomson-geopriv-uncertainty-06 (work in progress),		draft-thomson-geopriv-uncertainty-07 (work in progress),
	March 2011.		March 2012.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.
	[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for		[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
	Presence and Instant Messaging", RFC 2778, February 2000.		Presence and Instant Messaging", RFC 2778, February 2000.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,		[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,
	"Threat Analysis of the Geopriv Protocol", RFC 3694,		"Threat Analysis of the Geopriv Protocol", RFC 3694,
	February 2004.		February 2004.
	[RFC4079] Peterson, J., "A Presence Architecture for the		[RFC4079] Peterson, J., "A Presence Architecture for the
	Distribution of GEOPRIV Location Objects", RFC 4079,		Distribution of GEOPRIV Location Objects", RFC 4079,
	July 2005.		July 2005.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)		[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)", RFC 4825, May 2007.		Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
	[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,		[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,
	December 2007.		December 2007.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
			[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.
	[duckham05]		[duckham05]
	Duckham, M. and L. Kulik, "A formal model of obfuscation		Duckham, M. and L. Kulik, "A formal model of obfuscation
	and negotiation for location privacy. In Proc. of the 3rd		and negotiation for location privacy. In Proc. of the 3rd
	International Conference PERVASIVE 2005,Munich, Germany",		International Conference PERVASIVE 2005,Munich, Germany",
	May 2005.		May 2005.
	[duckham10]		[duckham10]
	Duckham, M., "Moving forward: Location privacy and		Duckham, M., "Moving forward: Location privacy and
	location awareness. In Proc. 3rd ACM SIGSPATIAL GIS		location awareness. In Proc. 3rd ACM SIGSPATIAL GIS
	Workshop on Security and Privacy in GIS and LBS		Workshop on Security and Privacy in GIS and LBS
	skipping to change at page 48, line 5 ¶		skipping to change at page 49, line 5 ¶
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082		Richardson, Texas 75082
	USA		USA
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	John B. Morris, Jr.		John B. Morris, Jr.
	Email: ietf@jmorris.org		Email: ietf@jmorris.org
	Martin Thomson		Martin Thomson
	Commscope		Microsoft
	Andrew Building (39)		3210 Porter Drive
	University of Wollongong Campus, Wollongong, NSW 2522		Palo Alto, CA 94304
	AU		US
	Phone: +61 2 4221 2915		Phone: +1 650-353-1925
	Email: martin.thomson@commscope.com		Email: martin.thomson@gmail.com
End of changes. 56 change blocks.
	127 lines changed or deleted		165 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/