< draft-ietf-geopriv-policy-11.txt		draft-ietf-geopriv-policy-12.txt >
	GEOPRIV H. Schulzrinne, Ed.		GEOPRIV H. Schulzrinne, Ed.
	Internet-Draft Columbia U.		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig, Ed.		Intended status: Standards Track H. Tschofenig, Ed.
	Expires: August 6, 2007 Siemens Networks GmbH & Co KG		Expires: November 23, 2007 Nokia Siemens Networks
	J. Morris		J. Morris
	CDT		CDT
	J. Cuellar		J. Cuellar
	Siemens		Siemens
	J. Polk		J. Polk
	Cisco		Cisco
	February 2, 2007		May 22, 2007
	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-11.txt		draft-ietf-geopriv-policy-12.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 6, 2007.		This Internet-Draft will expire on November 23, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines an authorization policy language for controling		This document defines an authorization policy language for controling
	access to location information. It extends the Common Policy		access to location information. It extends the Common Policy
	authorization framework to provide location-specific access control.		authorization framework to provide location-specific access control.
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13		6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13
	6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13		6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13
	6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14		6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14
	6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15		6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1. Rule Example with Civic Location Condition . . . . . . . . 16		7.1. Rule Example with Civic Location Condition . . . . . . . . 16
	7.2. Rule Example with Geodetic Location Condition . . . . . . 17		7.2. Rule Example with Geodetic Location Condition . . . . . . 17
	7.3. Rule Example with Civic and Geodetic Location Condition . 18		7.3. Rule Example with Civic and Geodetic Location Condition . 18
	7.4. Rule Example with Location-based Transformations . . . . . 19		7.4. Rule Example with Location-based Transformations . . . . . 19
	8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 22		8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 22
	9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 23		9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 23
	10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 25		10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 25
	10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25		10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 25		10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 25
	10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 25		10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25		10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25
	10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25		10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25
	10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25		10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25
	10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26		10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26
	10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26		10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 32		13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	13.2. Informative References . . . . . . . . . . . . . . . . . . 32		13.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	Intellectual Property and Copyright Statements . . . . . . . . . . 37		Intellectual Property and Copyright Statements . . . . . . . . . . 37
	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 [1], a		access to preserve the privacy of humans. In RFC 3693 [6], 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) [2] can restrict how long the Location Recipient is		Object (PIDF-LO) [7] can restrict how long the Location Recipient is
	allowed to retain the information, and it can prohibit further		allowed to retain the information, and it can prohibit further
	distribution. It also contains a reference to an enhanced rule set		distribution. It also contains a reference to an enhanced rule set
	and a human readable privacy policy. The basic rule set, however,		and a human readable privacy policy. The basic rule set, however,
	does not allow to control access to location information based on		does not allow to control access to location information based on
	specific Location Recipients. This document describes an enhanced		specific Location Recipients. This document describes an enhanced
	rule set that provides richer constraints on the distribution of LOs.		rule set that provides richer constraints on the distribution of LOs.
	The rule set allows the entity that uses the rules defined in this		The rule set allows the entity that uses the rules defined in this
	document to restrict the retention and to enforce access restrictions		document to restrict the retention and to enforce access restrictions
	on location data, including prohibiting any dissemination to		on location data, including prohibiting any dissemination to
	particular individuals, during particular times or when the Target is		particular individuals, during particular times or when the Target is
	located in a specific region. The RM can also stipulate that only		located in a specific region. The RM can also stipulate that only
	certain parts of the Location Object are to be distributed to		certain parts of the Location Object are to be distributed to
	recipients or that the resolution of parts of the Location Object is		recipients or that the resolution of parts of the Location Object is
	reduced.		reduced.
	The typical sequence of operations is as follows. A Location Server		The typical sequence of operations is as follows. A Location Server
	receives a query for location information for a particular Target,		receives a query for location information for a particular Target,
	via the using protocol [1]. The using protocol provides the identity		via the using protocol [6]. The using protocol provides the identity
	of the requestor, either at the time of the query or when subscribing		of the requestor, either at the time of the query or when subscribing
	to the location information. The authenticated identity of the		to the location information. The authenticated identity of the
	Location Recipient, together with other information provided by the		Location Recipient, together with other information provided by the
	using protocol or generally available to the server, is then used for		using protocol or generally available to the server, is then used for
	searching through the rule set. If more than one rule matches the		searching through the rule set. If more than one rule matches the
	condition element, then the combined permission is evaluated		condition element, then the combined permission is evaluated
	according to the description in Section 10 of [3]. The result of the		according to the description in Section 10 of [1]. The result of the
	rule evalation is applied to the location information, yielding a		rule evalation is applied to the location information, yielding a
	possibly modified Location Object that is delivered to the Location		possibly modified Location Object that is delivered to the Location
	Recipient.		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 (i.e.,		information from the Location Server to the Location Recipient (i.e.,
	the using protocol; see RFC 3693 [1]).		the using protocol; see RFC 3693 [6]).
	This document extends the Common Policy framework defined in [3].		This document extends the Common Policy framework defined in [1].
	That document provides an abstract framework for expressing		That document provides an abstract framework for expressing
	authorization policy rules. As specified there, each such rule		authorization rules. As specified there, each such rule consists of
	consists of conditions, actions and transformations. Conditions		conditions, actions and transformations. Conditions determine under
	determine under which circumstances the entity executing the rules,		which circumstances the entity executing the rules, for example a
	for example a Location Server, is permitted to apply actions and		Location Server, is permitted to apply actions and transformations.
	transformations. Transformations regulate in a location information		Transformations regulate in a location information context how a
	context how a Location Server modifies the information elements that		Location Server modifies the information elements that are returned
	are returned to the requestor, for example, by reducing the		to the requestor, for example, by reducing the granularity of
	granularity of returned location information.		returned location information.
	The XML schema defined in Section 9 extends the Common Policy schema		The XML schema defined in Section 9 extends the Common Policy schema
	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 [4].		document are to be interpreted as described in RFC 2119 [2].
	This document reuses the terminology of RFC 3693 [1], such as		This document reuses the terminology of RFC 3693 [6], 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 [1] uses the term Target to identify the object or person		RFC 3693 [6] uses the term Target to identify the object or person
	of which location information is required. The presence model		of which location information is required. The presence model
	described in RFC 2778 [11] uses the term presentity to describe		described in RFC 2778 [8] uses the term presentity to describe the
	the entity that provides presence information to a presence		entity that provides presence information to a presence service.
	service. A Presentity in a presence system is a Target in a		A Presentity in a presence system is a Target in a location
	location information system.		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 [1]. A watcher in a presence		(LR) in the terminology of RFC 3693 [6]. A watcher in a presence
	system, i.e., an entity that requests presence information about a		system, i.e., an entity that requests presence information about a
	presentity, is a Location Recipient in a location information		presentity, is a Location Recipient in a location information
	system.		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 rules. Each rule has a condition,		contains an unordered list of (policy) rules. Each rule has a
	an action and a transformation component. The terms		condition, an action and a transformation component.
	'authorization policy', 'policy', 'rule set', 'authorization
	policy rule', 'policy rule' and 'rule' are used interchangeable.
	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.
	The term 'using protocol' is defined in [1] and refers to the		The term 'using protocol' is defined in [6] and refers to the
	protocol that is used to request access to and to return privacy		protocol that is used to request access to and to return privacy
	sensitive data items.		sensitive data items.
	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 [12],		geolocation privacy architecture is, as motivated in RFC 4079 [9],
	aligned with the presence architecture and a Presence Server is		aligned with the presence architecture and a Presence Server is
	therefore an entity that distributes location information along with		therefore an entity that distributes location information along with
	other presence-specific XML data elements.		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 [3]. Geolocation authorization		according to the schema defined in [1]. Geolocation authorization
	documents inherit the MIME type of common policy documents,		documents inherit the MIME type of common policy documents,
	application/auth-policy+xml. As described in [3], this document is		application/auth-policy+xml. As described in [1], this document is
	composed of rules which contain three parts - conditions, actions,		composed of rules which contain three parts - conditions, actions,
	and transformations. Each action or transformation, which is also		and transformations. Each action or transformation, which is also
	called a permission, has the property of being a positive grant of		called a permission, has the property of being a positive grant of
	information to the Location Recipient. As a result, there is a well-		information to the Location Recipient. As a result, there is a well-
	defined mechanism for combining actions and transformations obtained		defined mechanism for combining actions and transformations obtained
	from several sources. This mechanism is privacy safe, since the lack		from several sources. This mechanism is privacy safe, since the lack
	of any action or transformation can only result in less information		of any action or transformation can only result in less information
	being presented to a Location Recipient.		being presented to a Location Recipient.
	3.2. Rule Transport		3.2. Rule Transport
	There are two ways how the authorization rules described in this		There are two ways how the authorization rules described in this
	document may be conveyed between different parties:		document may be conveyed between different parties:
	o RFC 4119 [2] allows enhanced authorization policies to be		o RFC 4119 [7] allows enhanced authorization policies to be
	referenced via a Uniform Resource Locator (URL) in the 'ruleset-		referenced via a Uniform Resource Locator (URL) in the 'ruleset-
	reference' element. The ruleset-reference' element is part of the		reference' element. The ruleset-reference' element is part of the
	basic rules that always travel with the Location Object.		basic rules that always travel with the Location Object.
	o Authorization policies might, for example, also be stored at a		o Authorization policies might, for example, also be stored at a
	Location Server / Presence Server. The Rule Maker therefore needs		Location Server / Presence Server. The Rule Maker therefore needs
	to use a protocol to create, modify and delete the authorization		to use a protocol to create, modify and delete the authorization
	policies defined in this document. Such a protocol is available		policies defined in this document. Such a protocol is available
	with the Extensible Markup Language (XML) Configuration Access		with the Extensible Markup Language (XML) Configuration Access
	Protocol (XCAP) [5].		Protocol (XCAP) [10].
	4. Location-specific Conditions		4. Location-specific Conditions
	This section describes the location-specific conditions of a rule,		This section describes the location-specific conditions of a rule,
	namely the civic and geodetic location conditions. The <conditions>		namely the civic and geodetic location conditions. The <conditions>
	element MAY contain zero, one or an unbounded number of <location-		element contains zero, one or an unbounded number of <location-
	condition> child element(s). Providing more than one <location-		condition> child element(s). Providing more than one <location-
	condition> child element may not be useful since all child elements		condition> child element may not be useful since all child elements
	of the <conditions> element must evaluate to TRUE in order for the		of the <conditions> element must evaluate to TRUE in order for the
	<conditions> element to be TRUE. The <location-condition> element		<conditions> element to be TRUE. The <location-condition> element
	MUST contain at least one <location> child element. The <location-		MUST contain at least one <location> child element. The <location-
	condition> element evaluates to TRUE if any of its child elements is		condition> element evaluates to TRUE if any of its child elements is
	TRUE, i.e., a logical OR.		TRUE, i.e., a logical OR.
	A location profile needs to describe under what conditions each		A location profile needs to describe under what conditions each
	<location> element evaluates to TRUE. This document defines two		<location> element evaluates to TRUE. This document defines two
	location profiles, one civic and one geodetic location profile.		location profiles, one civic and one geodetic location profile.
	The <location-condition> and the <location> elements provide		The <location-condition> and the <location> elements provide
	extension points. If an extension is not understood by the entity		extension points. If an extension is not understood by the entity
	evaluating the rules then this rule evaluates to FALSE.		evaluating the rules then this rule evaluates to FALSE.
	4.1. Geodetic Location Condition Profile		4.1. Geodetic Location Condition Profile
	The geodetic location profile is identified by the token 'geodetic-		The geodetic location profile is identified by the token 'geodetic-
	condition'. Rule Makers use this profile by placing a GML [6]		condition'. Rule Makers use this profile by placing a GML [3]
	<Polygon> element within the <location> element.		<Polygon> element within the <location> element.
	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 Polygon. This might require a point-		Target is within the described Polygon. This might require a point-
	in-polygon, polygon-in-polygon, or a similar computation. If the		in-polygon, polygon-in-polygon, or a similar computation. If the
	geodetic location of the Target is unknown then the <location>		geodetic location of the Target is unknown then the <location>
	element containing the information for the geodetic location profile		element containing the information for the geodetic location profile
	evaluates to FALSE.		evaluates to FALSE.
	The polygon that uses the "gml:Polygon" element is specified by a		The polygon that uses the "gml:Polygon" element is specified by a
	sequence of points. A polygon requires at least four points, where		sequence of points. A polygon requires at least four points, where
	the first and last point MUST be the same.		the first and last point MUST be the same.
	Points specified in a polygon MUST be coplanar. However,
	implementations SHOULD be prepared to accept small variations that
	might occur depending on whether the the polygon is specified on a
	plane in space, or only relative to the ellipsoid. To avoid
	implementation complexity, implementations MAY choose to not support
	polygons that include varying altitude. Therefore, two polygon forms
	are permitted: polygons specified using EPSG 4326, and polygons
	specified using EPSG 4979 with a constant altitude value.
	Interpolation between points is linear, as defined for the "gml:
	LinearRing" element. Implementations SHOULD minimize this
	interpolation error by ensuring that the sides of polygons are as
	short as possible.
	Implementations are REQUIRED to support the following coordinate		Implementations are REQUIRED to support the following coordinate
	reference systems based on WGS 84 [7]. These are identified using		reference systems based on WGS 84 [4]. These are identified using
	the European Petroleum Survey Group (EPSG) Geodetic Parameter		the European Petroleum Survey Group (EPSG) Geodetic Parameter
	Dataset, as formalized by the Open Geospatial Consortium (OGC):		Dataset, as 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.
	3D: WGS 84 (latitude, longitude, altitude), as identified by the URN		3D: WGS 84 (latitude, longitude, altitude), as identified by the URN
	"urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS.		"urn:ogc:def:crs:EPSG::4979". This is a three 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
	sub-elements. The "srsDimension" attribute MUST be omitted, since		sub-elements. The "srsDimension" attribute MUST be omitted, since
	the number of dimensions in these CRSs is known.		the number of dimensions in these CRSs is known.
			Points specified in a polygon MUST be coplanar. However,
			implementations SHOULD be prepared to accept small variations that
			might occur depending on whether the the polygon is specified on a
			plane in space, or only relative to the ellipsoid. To avoid
			implementation complexity, implementations MAY choose to not support
			polygons that include varying altitude. Therefore, two polygon forms
			are permitted: polygons specified using EPSG 4326, and polygons
			specified using EPSG 4979 with a constant altitude value.
			Interpolation between points is linear, as defined for the "gml:
			LinearRing" element. Implementations SHOULD minimize this
			interpolation error by ensuring that the sides of polygons are as
			short as possible.
	4.2. Civic Location Condition Profile		4.2. Civic Location Condition Profile
	The civic location profile is identified by the token 'civic-		The civic location profile is identified by the token 'civic-
	condition'. Rule Makers use this profile by placing a <civicAddress>		condition'. Rule Makers use this profile by placing a <civicAddress>
	element, defined in [8], within the <location> element.		element, defined in [5], within the <location> element.
	All child elements of <location> element that carry civicAddress		All child elements of <location> element that carry civicAddress
	elements MUST evaluate to TRUE (i.e., logical AND) in order for the		elements MUST evaluate to TRUE (i.e., logical AND) in order for the
	<location> element to evaluate to TRUE. For each element value a		<location> element to evaluate to TRUE. For each element value a
	string-by-string comparison is performed.		string-by-string comparison is performed.
	If the civic location of the Target is unknown, then the <location>		If the civic location of the Target is unknown, then the <location>
	element containing the information for the civic location profile		element containing the information for the civic location profile
	evaluates to FALSE. This case may occur, for example, if location		evaluates to FALSE. This case may occur, for example, if location
	information has been removed by earlier transmitters of location		information has been removed by earlier transmitters of location
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 24 ¶
	6.1. Set Retransmission-Allowed		6.1. Set Retransmission-Allowed
	This element asks the LS to change or set the value of the		This element asks the LS to change or set the value of the
	<retransmission-allowed> element in the PIDF-LO. The data type of		<retransmission-allowed> element in the PIDF-LO. The data type of
	the <set-retransmission-allowed> element is a boolean.		the <set-retransmission-allowed> element is a boolean.
	If the value of the <set-retransmission-allowed> element is set to		If the value of the <set-retransmission-allowed> element is set to
	TRUE then the <retransmission-allowed> element in the PIDF-LO MUST be		TRUE then the <retransmission-allowed> element in the PIDF-LO MUST be
	set to TRUE. If the value of the <set-retransmission-allowed>		set to TRUE. If the value of the <set-retransmission-allowed>
	element is set to FALSE, then the <retransmission-allowed> element in		element is set to FALSE, then the <retransmission-allowed> element in
	the PIDF-LO MUST to be set to FALSE.		the PIDF-LO MUST be set to FALSE.
	If the <set-retransmission-allowed> element is absent then the value		If the <set-retransmission-allowed> element is absent then the value
	of the <retransmission-allowed> element in the PIDF-LO MUST be kept		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		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
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 15 ¶
	If the <set-note-well> element is absent, then the value of the		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		<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		PIDF-LO is created for the first time, then no content is provided
	for the <note-well> element.		for the <note-well> element.
	6.4. Keep Ruleset Reference		6.4. Keep Ruleset Reference
	This transformation allows to influence whether the <external-		This transformation allows to influence whether the <external-
	ruleset> element in the PIDF-LO carries the extended authorization		ruleset> element in the PIDF-LO carries the extended authorization
	rules defined in [3]. The data type of the <keep-rule-reference>		rules defined in [1]. The data type of the <keep-rule-reference>
	element is Boolean.		element is Boolean.
	If the value of the <keep-rule-reference> element is set to TRUE,		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		then the <external-ruleset> element in the PIDF-LO is kept unchanged
	when included. If the value of the <keep-rule-reference> element is		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		set to FALSE, then the <external-ruleset> element in the PIDF-LO MUST
	NOT contain a reference. The reference to the ruleset is removed and		NOT contain a reference. The reference to the ruleset is removed and
	no rules are carried as MIME bodies (in case of CID URIs).		no rules are carried as MIME bodies (in case of CID URIs).
	If the <keep-rule-reference> element is absent, then the value of the		If the <keep-rule-reference> element is absent, then the value of the
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 18 ¶
	profile attribute MUST NOT be included.		profile attribute MUST NOT be included.
	6.5.1. Civic Location Profile		6.5.1. Civic Location Profile
	This profile uses the token 'civic-transformation'. This profile		This profile uses the token 'civic-transformation'. This profile
	allows civic location transformations to be specified by means of the		allows civic location transformations to be specified by means of the
	<provide-civic> element that restricts the level of civic location		<provide-civic> element that restricts the level of civic location
	information the LS is permitted to disclose. The symbols of these		information the LS is permitted to disclose. The symbols of these
	levels are: 'country', 'region', 'city', 'building', 'full'. Each		levels are: 'country', 'region', 'city', 'building', 'full'. Each
	level is given by a set of civic location data items such as		level is given by a set of civic location data items such as
	<country> and <A1>, ..., <POM>, as defined in [8]. Each level		<country> and <A1>, ..., <POM>, as defined in [5]. Each level
	includes all elements included by the lower levels.		includes all elements included by the lower levels.
	The 'country' level includes only the <country> element; the 'region'		The 'country' level includes only the <country> element; the 'region'
	level adds the <A1> element; the 'city' level adds the <A2> and <A3>		level adds the <A1> element; the 'city' level adds the <A2> and <A3>
	elements; the 'building' level and the 'full' level add further civic		elements; the 'building' level and the 'full' level add further civic
	location data as shown below.		location data as shown below.
	full		full
	{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,		{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
	<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,		<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 7 ¶
	0.01 89.0000		0.01 89.0000
	0.1 43.9000		0.1 43.9000
	1 39.4000		1 39.4000
	10 38.9490		10 38.9490
	100 38.9037		100 38.9037
	The schema of the <provide-geo> element is defined in Section 8.		The schema of the <provide-geo> element is defined in Section 8.
	7. Examples		7. Examples
	This section provides a few examples for authorization policy rules		This section provides a few examples for authorization rules using
	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.
	Requests match only if the Target is at a civic location with country		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		set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to
	'Munich', city division (A4) set to 'Perlach', street name (A6) set		'Munich', city division (A4) set to 'Perlach', street name (A6) set
	to 'Otto-Hahn-Ring' and house number (HNO) set to '6'.		to 'Otto-Hahn-Ring' and house number (HNO) set to '6'.
	No actions and transformation child elements are provided in this		No actions and transformation child elements are provided in this
	rule example. The actions and transformation could include presence		rule example. The actions and transformation could include presence
	specific information when the Geolocation Policy framework is applied		specific information when the Geolocation Policy framework is applied
	to the Presence Policy framework (see [13]).		to the Presence Policy framework (see [11]).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rule id="AA56i09">		<rule id="AA56i09">
	<conditions>		<conditions>
	<gp:location-condition>		<gp:location-condition>
	<gp:location profile="civic-condition"		<gp:location profile="civic-condition"
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>DE</country>		<country>DE</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A4>Perlach</A4>		<A4>Perlach</A4>
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 15 ¶
	7.2. Rule Example with Geodetic Location Condition		7.2. Rule Example with Geodetic Location Condition
	This example illustrates a rule that employs the geodetic location		This example illustrates a rule that employs the geodetic location
	condition. The rule matches if the current location of the Target is		condition. The rule matches if the current location of the Target is
	inside the area specified by the polygon. The polygon uses the EPSG		inside the area specified by the polygon. The polygon uses the EPSG
	4326 coordinate reference system. No altitude is included in this		4326 coordinate reference system. No altitude is included in this
	example.		example.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rule id="BB56A19">		<rule id="BB56A19">
	<conditions>		<conditions>
	<gp:location-condition>		<gp:location-condition>
	<gp:location profile="geodetic-condition">		<gp:location profile="geodetic-condition">
	<gml:Polygon		<gml:Polygon
	srsName="urn:ogc:def:crs:EPSG::4326"		srsName="urn:ogc:def:crs:EPSG::4326"
	xmlns:gml="http://www.opengis.net/gml">		xmlns:gml="http://www.opengis.net/gml">
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	</ruleset>		</ruleset>
	The following alternative example shows the same polygon with a		The following alternative example shows the same polygon with a
	constant altitude included that is specified using EPSG 4979 and the		constant altitude included that is specified using EPSG 4979 and the
	"gml:posList" element. The "gml:posList" element is interpreted as a		"gml:posList" element. The "gml:posList" element is interpreted as a
	list with the dimension of the CRS indicating how many values are		list with the dimension of the CRS indicating how many values are
	required for each point.		required for each point.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rule id="BB56A19">		<rule id="BB56A19">
	<conditions>		<conditions>
	<gp:location-condition>		<gp:location-condition>
	<gp:location profile="geodetic-condition">		<gp:location profile="geodetic-condition">
	<gml:Polygon		<gml:Polygon
	srsName="urn:ogc:def::crs:EPSG::4979"		srsName="urn:ogc:def::crs:EPSG::4979"
	xmlns:gml="http://www.opengis.net/gml">		xmlns:gml="http://www.opengis.net/gml">
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	7.3. Rule Example with Civic and Geodetic Location Condition		7.3. Rule Example with Civic and Geodetic Location Condition
	This example illustrates a rule that employs a mixed civic and		This example illustrates a rule that employs a mixed civic and
	geodetic location condition. Depending on the available type of		geodetic location condition. Depending on the available type of
	location information, namely civic or geodetic location information,		location information, namely civic or geodetic location information,
	one of the location elements may match.		one of the location elements may match.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rule id="AA56i09">		<rule id="AA56i09">
	<conditions>		<conditions>
	<gp:location-condition>		<gp:location-condition>
	<gp:location profile="civic-condition"		<gp:location profile="civic-condition"
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>DE</country>		<country>DE</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A4>Perlach</A4>		<A4>Perlach</A4>
	skipping to change at page 20, line 8 ¶		skipping to change at page 20, line 8 ¶
	This example shows the transformations specified in this document.		This example shows the transformations specified in this document.
	The <provide-civic> element indicates that the available civic		The <provide-civic> element indicates that the available civic
	location information is reduced to building level granularity. If		location information is reduced to building level granularity. If
	geodetic location information is requested then a granularity		geodetic location information is requested then a granularity
	reduction is provided as well.		reduction is provided as well.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">		xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
	<rule id="AA56i09">		<rule id="AA56i09">
	<conditions/>		<conditions/>
	<actions/>		<actions/>
	<transformations>		<transformations>
	<gp:set-retransmission-allowed>false		<gp:set-retransmission-allowed>false
	</gp:set-retransmission-allowed>		</gp:set-retransmission-allowed>
	<gp:set-retention-expiry>86400</gp:set-retention-expiry>		<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 xml:lang="en">My privacy policy goes in here.
	skipping to change at page 21, line 7 ¶		skipping to change at page 21, line 7 ¶
	</transformations>		</transformations>
	</rule>		</rule>
	</ruleset>		</ruleset>
	The following rule describes the short-hand notation for making the		The following rule describes the short-hand notation for making the
	current location of the Target available to Location Recipients		current location of the Target available to Location Recipients
	without granularity reduction.		without granularity reduction.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"		<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rule id="AA56ia9">		<rule id="AA56ia9">
	<conditions/>		<conditions/>
	<actions/>		<actions/>
	<transformations>		<transformations>
	<gp:provide-location/>		<gp:provide-location/>
	</transformations>		</transformations>
	</rule>		</rule>
	</ruleset>		</ruleset>
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	maxOccurs="1" default="0"/>		maxOccurs="1" default="0"/>
	<xs:element name="altitude-resolution"		<xs:element name="altitude-resolution"
	type="xs:double" minOccurs="0"		type="xs:double" minOccurs="0"
	maxOccurs="1" default="0"/>		maxOccurs="1" default="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	9. XML Schema		9. XML Schema for Geolocation Policy
	This section presents the XML schema that defines the Geolocation		This section presents the XML schema that defines the Geolocation
	Policy schema described in this document. The Geolocation Policy		Policy schema described in this document. The Geolocation Policy
	schema extends the Common Policy schema (see [3]) by introducing new		schema extends the Common Policy schema (see [1]) by introducing new
	members of the 'condition' and 'transformation' substitution groups		members of the 'condition' and 'transformation' substitution groups
	whose heads (namely the elements <condition> and <transformation>).		whose heads (namely the elements <condition> and <transformation>).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:geolocation-policy"		targetNamespace="urn:ietf:params:xml:ns:geolocation-policy"
	xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"		xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
	xmlns:cp="urn:ietf:params:xml:ns:common-policy"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		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-->		<!-- This import brings in the XML language attribute xml:lang-->
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"		<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	schemaLocation="http://www.w3.org/2001/xml.xsd"/>		schemaLocation="http://www.w3.org/2001/xml.xsd"/>
	<!-- Geopriv Conditions -->		<!-- Geopriv Conditions -->
	<xs:element name="location-condition"		<xs:element name="location-condition"
	type="gp:locationconditionType"/>		type="gp:locationconditionType"/>
	<xs:complexType name="locationconditionType">		<xs:complexType name="locationconditionType">
	skipping to change at page 25, line 10 ¶		skipping to change at page 25, line 10 ¶
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	10. XCAP Usage		10. XCAP Usage
	The following section defines the details necessary for clients to		The following section defines the details necessary for clients to
	manipulate geolocation privacy documents from a server using XCAP.		manipulate geolocation privacy documents from a server using XCAP.
	If used as part of a presence system, it uses the same AUID as those		If used as part of a presence system, it uses the same AUID as those
	rules. See [13] for a description of the XCAP usage in context with		rules. See [11] for a description of the XCAP usage in context with
	presence authorization rules.		presence authorization rules.
	10.1. Application Unique ID		10.1. Application Unique ID
	XCAP requires application usages to define a unique application usage		XCAP requires application usages to define a unique application usage
	ID (AUID) in either the IETF tree or a vendor tree. This		ID (AUID) in either the IETF tree or a vendor tree. This
	specification defines the "geolocation-policy" AUID within the IETF		specification defines the "geolocation-policy" AUID within the IETF
	tree, via the IANA registration in Section 11.		tree, via the IANA registration in Section 11.
	10.2. XML Schema		10.2. XML Schema
	skipping to change at page 27, line 15 ¶		skipping to change at page 27, line 15 ¶
	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
	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, Hannes Tschofenig
	(hannes.tschofenig@siemens.com).		(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
	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, Hannes Tschofenig
	(hannes.tschofenig@siemens.com).		(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 28, line 30 ¶		skipping to change at page 28, line 30 ¶
	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 seeks to create a registry of location profile names
	for the Geolocation Policy framework. Profile names are XML tokens.		for the Geolocation Policy framework. Profile names are XML tokens.
	This registry will operate in accordance with RFC 2434 [9], Standards		This registry will operate in accordance with RFC 2434 [12],
	Action.		Standards Action.
	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		URI: urn:ietf:params:xml:schema:basic-location-profiles
	Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig		Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
	(hannes.tschofenig@siemens.com).		(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 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
	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, Hannes Tschofenig
	(hannes.tschofenig@siemens.com).		(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 29, line 47 ¶		skipping to change at page 29, line 47 ¶
	[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 Usage ID (AUID) according
	to the IANA procedures defined in [5].		to the IANA procedures defined in [10].
	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. Security Considerations		12. Security Considerations
	This document aims to make it simple for users to prevent the		This document aims to make it simple for users to prevent the
	unintended disclosure of private information to third parties.		unintended disclosure of private information to third parties. This
	Security requirements are described in [1] and a discussion of		is accomplished through the usage of authorization policies.
	generic security threats is available with [10]. Aspects of		Security requirements are described in [6] and a discussion of
			generic security threats is available with [13]. Aspects of
	combining permissions in cases of multiple occurrence are treated in		combining permissions in cases of multiple occurrence are treated in
	[3]). The concept of location-based conditions are introduced in		[1]). The concept of location-based conditions are introduced in
	Section 4 and mechanisms to reduce the granularity of returned		Section 4 and mechanisms to reduce the granularity of returned
	location information is specified in Section 6.		location information is specified in Section 6.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.		[1] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
	Polk, "Geopriv Requirements", RFC 3693, February 2004.		J., and J. Rosenberg, "Common Policy: A Document Format for
			Expressing Privacy Preferences", RFC 4745, February 2007.
	[2] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.
	[3] Schulzrinne, H., "Common Policy: A Document Format for
	Expressing Privacy Preferences",
	draft-ietf-geopriv-common-policy-11 (work in progress),
	August 2006.
	[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	[5] Rosenberg, J., "The Extensible Markup Language (XML)		[3] OpenGIS, "OpenGIS Geography Markup Language (GML)
	Configuration Access Protocol (XCAP)",
	draft-ietf-simple-xcap-12 (work in progress), October 2006.
	[6] 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, January 2003.		http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003.
	[7] OpenGIS, "US National Imagery and Mapping Agency, "Department		[4] OpenGIS, "US National Imagery and Mapping Agency, "Department
	of Defense (DoD) World Geodetic System 1984 (WGS 84), Third		of Defense (DoD) World Geodetic System 1984 (WGS 84), Third
	Edition, NIMA TR8350.2", , January 2000.		Edition, NIMA TR8350.2", , January 2000.
	[8] Thomson, M. and J. Winterbottom, "Revised Civic Location Format		[5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
	for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in		for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
	progress), September 2006.		progress), February 2007.
	[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		13.2. Informative References
	Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.
	[10] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat		[6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
	Analysis of the Geopriv Protocol", RFC 3694, February 2004.		Polk, "Geopriv Requirements", RFC 3693, February 2004.
	13.2. Informative References		[7] Peterson, J., "A Presence-based GEOPRIV Location Object
			Format", RFC 4119, December 2005.
	[11] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence		[8] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
	and Instant Messaging", RFC 2778, February 2000.		and Instant Messaging", RFC 2778, February 2000.
	[12] Peterson, J., "A Presence Architecture for the Distribution of		[9] Peterson, J., "A Presence Architecture for the Distribution of
	GEOPRIV Location Objects", RFC 4079, July 2005.		GEOPRIV Location Objects", RFC 4079, July 2005.
	[13] Rosenberg, J., "Presence Authorization Rules",		[10] Rosenberg, J., "The Extensible Markup Language (XML)
	draft-ietf-simple-presence-rules-08 (work in progress),		Configuration Access Protocol (XCAP)",
	October 2006.		draft-ietf-simple-xcap-12 (work in progress), October 2006.
			[11] Rosenberg, J., "Presence Authorization Rules",
			draft-ietf-simple-presence-rules-09 (work in progress),
			March 2007.
			[12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
			[13] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
			Analysis of the Geopriv Protocol", RFC 3694, February 2004.
	[14] Thomson, M., "Geodetic Shapes for the Representation of		[14] Thomson, M., "Geodetic Shapes for the Representation of
	Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03		Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03
	(work in progress), December 2006.		(work in progress), December 2006.
	[15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based Location
	Configuration Information", RFC 3825, July 2004.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	This document is informed by the discussions within the IETF GEOPRIV		This document is informed by the discussions within the IETF GEOPRIV
	working group, including discussions at the GEOPRIV interim meeting		working group, including discussions at the GEOPRIV interim meeting
	in Washington, D.C., in 2003.		in Washington, D.C., in 2003.
	We particularly want to thank Allison Mankin <mankin@psg.com>,		We particularly want to thank Allison Mankin <mankin@psg.com>,
	Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton		Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
	<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon		<anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
	Peterson <jon.peterson@neustar.biz> for their help in improving the		Peterson <jon.peterson@neustar.biz> for their help in improving the
	quality of this document.		quality of this document.
	We would like to thank Christian Guenther for his help with an		We would like to thank Christian Guenther for his help with an
	earlier version of this document. Furthermore, we would like to		earlier version of this document. Furthermore, we would like to
	thank Johnny Vrancken for a several document reviews and the		thank Johnny Vrancken for his document reviews in September 2006,
	suggestions he provided between September 2006, December 2006 and		December 2006 and January 2007. James Winterbottom provided a
	January 2007. James Winterbottom provided a detailed review in		detailed review in November 2006.
	November 2006.
	This document uses text from [14]. Therefore, we would like to thank		This document uses text from [14]. Therefore, we would like to thank
	Martin Thomson for his work in [14].		Martin Thomson for his work in [14].
			We would like to thank Dan Romascanu, Yoshiko Chong and Jari
			Urpalainen for their last call comments.
	Authors' Addresses		Authors' Addresses
	Henning Schulzrinne (editor)		Henning Schulzrinne (editor)
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	USA		USA
	Phone: +1 212 939 7042		Phone: +1 212 939 7042
	Email: schulzrinne@cs.columbia.edu		Email: schulzrinne@cs.columbia.edu
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu/~hgs
	Hannes Tschofenig (editor)		Hannes Tschofenig (editor)
	Siemens Networks GmbH & Co KG		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	John B. Morris, Jr.		John B. Morris, Jr.
	Center for Democracy and Technology		Center for Democracy and Technology
	1634 I Street NW, Suite 1100		1634 I Street NW, Suite 1100
	Washington, DC 20006		Washington, DC 20006
	USA		USA
	Email: jmorris@cdt.org		Email: jmorris@cdt.org
	URI: http://www.cdt.org		URI: http://www.cdt.org
End of changes. 72 change blocks.
	131 lines changed or deleted		122 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/