< draft-thomson-geopriv-location-quality-00.txt		draft-thomson-geopriv-location-quality-01.txt >
	GEOPRIV M. Thomson		GEOPRIV M. Thomson
	Internet-Draft J. Winterbottom		Internet-Draft J. Winterbottom
	Intended status: Standards Track Andrew		Intended status: Standards Track Andrew
	Expires: June 23, 2008 December 21, 2007		Expires: November 28, 2008 May 27, 2008
	Specifying Location Quality Constraints in Location Protocols		Specifying Location Quality Constraints in Location Protocols
	draft-thomson-geopriv-location-quality-00.txt		draft-thomson-geopriv-location-quality-01
	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 34 ¶		skipping to change at page 1, line 34 ¶
	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 June 23, 2008.		This Internet-Draft will expire on November 28, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
			Parameters that define the expected quality of location information
			are defined for use in location protocols. These parameter can be
			used by a requester to indicate to a Location Server the desired
			constraints on the quality of the location information provided. If
			applicable, the Location Server is able to use this information to
			control how location information is determined. An optional
			indication of whether the quality constraints were met is defined to
			be provided by the Location Server alongside location information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions used in this document . . . . . . . . . . . . 4		1.1. Conventions used in this document . . . . . . . . . . . . 4
	2. Location Quality Operation . . . . . . . . . . . . . . . . . . 5		2. Location Quality Operation . . . . . . . . . . . . . . . . . . 5
	3. Location Quality Parameters . . . . . . . . . . . . . . . . . 6		3. Location Quality Objects . . . . . . . . . . . . . . . . . . . 6
	3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6		3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6
	3.1.1. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6		3.1.1. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6
	3.1.2. Required Civic Elements . . . . . . . . . . . . . . . 7		3.1.2. Required Civic Elements . . . . . . . . . . . . . . . 7
	3.1.3. Maximum Age . . . . . . . . . . . . . . . . . . . . . 8		3.1.3. Maximum Age . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Location Quality Indication . . . . . . . . . . . . . . . 8		3.2. Location Quality Indication . . . . . . . . . . . . . . . 8
	4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10		4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1. URN Sub-Namespace Registration for		6.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 14		urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 14
	6.2. XML Schema Registration for Measurement Schema . . . . . . 14		6.2. XML Schema Registration for Location Quality Schema . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 15		7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	7.2. Informative References . . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Location determination methods produce results of varying quality.		Location determination methods produce results of varying accuracy.
	In general, the quality of location information increases as the		In general, the accuracy of location information increases as the
	effort expended in generating the information increases. This		effort expended in generating the information increases. Accuracy is
	document provides XML extension objects that can be added to any		the primary aspect of the quality of location information that is
			relevant to a Location Recipient (LR), but other aspects of quality
			can also be significant, such as the currency of the data.
			This document provides XML extension objects that can be added to any
	protocol that provides location information. These elements provide		protocol that provides location information. These elements provide
	the ability to communicate location quality constraints to the		the ability to communicate location quality constraints to the
	location server.		location server.
	This document provides semantics, examples and security		This document provides semantics, examples and security
	considerations for the HELD protocol		considerations for the HELD protocol
	[I-D.ietf-geopriv-http-location-delivery]. Application of the		[I-D.ietf-geopriv-http-location-delivery]. Application of the
	parameters described in this document are out of scope.		parameters described in this document to other protocols is out of
			scope.
	Means for expressing the quality of location information is outlined		Means for expressing the quality of location information is outlined
	in [I-D.thomson-geopriv-uncertainty] and [GeoShape]. An entity		in [I-D.thomson-geopriv-uncertainty] and [GeoShape]. An entity
	requesting location information of an LS is unable to specify the		requesting location information of a Location Server (LS) is unable
	quality of the location that it ultimately receives. This is		to specify the quality of the location that it ultimately receives.
	inefficient because an LS either provides location information that		This is inefficient because an LS either provides location
	is inadequate for the intended task; or the LS could waste resources		information that is inadequate for the intended task; or the LS could
	generating location information that is of eccessively high quality.		waste resources generating location information that is of
			eccessively high quality.
	This document describes an optional HELD parameter that communicates		This document describes an optional HELD parameter that communicates
	location quality constraints to an LS. These constraints specify a		location quality constraints to an LS. These constraints specify a
	desired uncertainty at a certain confidence, plus the maximum		desired uncertainty at a certain confidence, plus the maximum
	acceptable age where location information is stored. Guidelines for		acceptable age where location information is stored. Guidelines for
	deterministically evaluating location information against these rules		deterministically evaluating location information against these rules
	are provided.		are provided.
	[I-D.busin-geopriv-location-qos-req] describes some of the benefits		Some of the benefits of providing an LS with location quality
	of providing an LS with location quality constraints. Location		constraints are described in [I-D.busin-geopriv-location-qos-req].
	quality constraints provide information that an LS can use in		Location quality constraints provide information that an LS can use
	deciding how to generate location information. For example, an LS		in deciding how to generate location information, if the LS uses a
	that is able to provide a location estimate with a sufficiently small		Location Generator as a source of location information. This is the
	uncertainty might be able to provide a response before the time		case for a Location Information Server (LIS) and the HELD protocol.
	indicated in the "responseTime".		For example, a LIS that is able to provide a location estimate with a
			sufficiently small uncertainty might be able to provide a response
			before the time indicated within the time indicated in the request
			(the "responseTime").
	This document also provides a means by which the LS is able to		This document also provides a means by which the LS is able to
	indicate if the location quality meets the constraints. These		indicate if the location quality meets the constraints. These
	parameters can be used by a Location Recipient to ensure that the		parameters can be used by a Location Recipient to ensure that the
	location is of adequate quality without requiring specific checking		location is of adequate quality without requiring specific checking
	(although the PIDF-LO should include sufficient information to		(although the PIDF-LO should include sufficient information to
	perform this check). Response parameters are optional, and are also		perform this check). Response parameters are optional; the presence
	used to indicate that the LS has understood the location quality		of a quality indication in the response also indicates that the LS
	constraints.		has understood the location quality constraints.
	This document provides solutions that address a subset of the		This document provides solutions that address a subset of the
	requirements in [I-D.busin-geopriv-location-qos-req].		requirements in [I-D.busin-geopriv-location-qos-req].
	1.1. Conventions used in this document		1.1. Conventions used in this document
	Terms and procedures relating to uncertainty and confidence are taken		Terms and procedures relating to uncertainty and confidence are taken
	from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology		from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology
	outlined in [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] is also		outlined in [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] is also
	assumed.		assumed.
	The term Location Server (LS) is used as a generic label. From the		The term Location Server (LS) is used as a generic label, since these
	perspective of this document, the LS could be a Location Information		paramters apply in all cases where location information is served to
	Server (LIS). Similarly, the term Location Recipient (LR) is used to		a requesting entity. From the perspective of this document, the LS
	refer to the requester of location information, which could be a		could be a Location Information Server (LIS). Similarly, the term
	Device or Target for HELD.		Location Recipient (LR) is used to refer to the requester of location
			information, which could be a Device or Target for HELD.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Location Quality Operation		2. Location Quality Operation
	Location quality parameters are provided by a Device or any other		Location quality parameters are provided by a Device or any other
	client of an LS in a location request message. Figure 1 shows an		client of an LS in a location request message. Figure 1 shows an
	example message.		example message.
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
	<locationType exact="true">geodetic</locationType>		<locationType exact="true">geodetic</locationType>
	<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">		<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
	<maxUncertainty confidence="95">		<maxUncertainty confidence="95">
	<horizontal>150</horizontal>		<horizontal>150</horizontal>
	<vertical>1000</vertical>		<vertical>1000</vertical>
	</maxUncertainty>		</maxUncertainty>
	<maxAge>PT30S</maxAge>		<maxAge>2008-05-27T05:47:55Z</maxAge>
	</quality>		</quality>
	</locationRequest>		</locationRequest>
	Figure 1		Figure 1: Example HELD Location Request
	A LS that supports the location quality element uses the information		A LS that supports the location quality element uses the information
	contained in the request to choose how it serves the query. The		contained in the request to choose how it serves the query. The
	response to this message contains a quality indicator element that		response to this message contains a quality indicator element that
	includes a list of the quality constraints that were met. Figure 2		includes a list of the quality constraints that were met. Figure 2
	shows a location response that includes a quality indicator.		shows a location response that includes a quality indicator.
	<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">		<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	entity="pres:user@example.com">		entity="pres:user@example.com">
	<!-- Actual location information omitted -->		<!-- Actual location information omitted -->
	</presence>		</presence>
	<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">		<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
	maxUncertainty/vertical maxAge		maxUncertainty/vertical maxAge
	</qualityInd>		</qualityInd>
	</locationResponse>		</locationResponse>
	Figure 2		Figure 2: Example HELD Location Response
	A LS doesn't indicate the quality of the location estimate in the		A LS doesn't indicate the quality of the location estimate in the
	quality indicator; quality information is included in the PIDF-LO.		quality indicator; quality information is included in the PIDF-LO.
	The quality indicator provides notice to its recipient that the		The quality indicator provides notice to its recipient that the
	requested quality was provided.		requested quality was provided.
	3. Location Quality Parameters		3. Location Quality Objects
	This section defines the format and semantics of the location quality		This section defines the format and semantics of the location quality
	parameters for requests and the indication that is included with		parameters for requests and the indication that is included with
	responses.		responses.
	3.1. Location Quality Request		3.1. Location Quality Request
	The "quality" element is included in a HELD request to indicate the		The "quality" element is included in a HELD request to indicate the
	constraints set by the Location Recipient (LR) on the quality of		constraints set by the Location Recipient (LR) on the quality of
	returned location information. This document defines three elements		returned location information. This document defines three elements
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	3.1.1. Maximum Uncertainty		3.1.1. Maximum Uncertainty
	The "maxUncertainty" element describes an upper limit on uncertainty		The "maxUncertainty" element describes an upper limit on uncertainty
	at a given confidence. Uncertainty is divided in to horizontal and		at a given confidence. Uncertainty is divided in to horizontal and
	vertical components. Horizontal uncertainty is the maximum distance		vertical components. Horizontal uncertainty is the maximum distance
	from the centroid of the area to the point in the shape furthest from		from the centroid of the area to the point in the shape furthest from
	the centroid on the horizontal plane. Vertical uncertainty is the		the centroid on the horizontal plane. Vertical uncertainty is the
	difference in altitude from the centroid to the point in the shape		difference in altitude from the centroid to the point in the shape
	with the greatest altitude.		with the greatest altitude.
	Note: A LS MAY provide location information using the Point shape		Note: An LS MAY provide location information using the Point shape
	and indicate that the requested uncertainty is met providing that		and indicate that the requested uncertainty is met providing that
	the LS has access to uncertainty information. However, this is		the LS has access to uncertainty information. However, this is
	NOT RECOMMENDED since the recipient has no way of verifying the		NOT RECOMMENDED since the LR has no way of verifying that the
	uncertainty.		uncertainty meets their requirements.
	The "horizontal" and "vertical" elements are numerical values that		The "horizontal" and "vertical" elements are numerical values that
	contain a decimal value in meters. Maximum uncertainty values MUST		contain a decimal value in meters. Maximum uncertainty values MUST
	be greater than zero.		be greater than zero.
	A location estimate that does not contain uncertainty (i.e. a Point		A location estimate that does not contain uncertainty (i.e. a Point
	shape), never meets location quality constraints. Where uncertainty		shape), never meets location quality constraints. Where uncertainty
	is unknown, it MUST be assumed to be infinite at any non-zero		is unknown, it MUST be assumed to be infinite at any non-zero
	confidence. In particular, this applies to vertical uncertainty		confidence. In particular, this applies to vertical uncertainty
	where the location estimate is two-dimensional only; location		where the location estimate is two-dimensional only; location
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	vertical uncertainty constraints.		vertical uncertainty constraints.
	The "confidence" attribute of this element includes the confidence		The "confidence" attribute of this element includes the confidence
	level (expressed as a percentage) that the uncertainty is evaluated		level (expressed as a percentage) that the uncertainty is evaluated
	at. Confidence is set to a default of 95%.		at. Confidence is set to a default of 95%.
	To evaluate uncertainty, the location estimate is first scaled so		To evaluate uncertainty, the location estimate is first scaled so
	that the confidence of the estimate matches (or exceeds) the		that the confidence of the estimate matches (or exceeds) the
	requested confidence. The LS MAY convert the shape of the		requested confidence. The LS MAY convert the shape of the
	uncertainty to a circle or a sphere prior to scaling to simply the		uncertainty to a circle or a sphere prior to scaling to simply the
	scaling process. For consistency, and contrary to the rules in		scaling process. For consistency -- and contrary to the rules in
	[I-D.thomson-geopriv-uncertainty], it is RECOMMENDED that a normal		[I-D.thomson-geopriv-uncertainty] -- it is RECOMMENDED that a normal
	PDF be used for all except where confidence is reduced for a		PDF be used for all location information except where confidence is
	rectangular PDF.		reduced for a rectangular PDF.
	Horizontal uncertainty is evalulated by removing the altitude and		Horizontal uncertainty is evalulated by removing the altitude and
	altitude uncertainty components from the location estimate. While		altitude uncertainty components from the location estimate. While
	removing altitude components from a location estimate might normally		removing altitude components from a location estimate might normally
	increase confidence, confidence MUST NOT be increased at this step;		increase confidence, confidence MUST NOT be increased at this step;
	the confidence value has already been considered. The shape is then		the confidence value has already been considered. The shape is then
	converted to a circle, if it is not already in that shape. The		converted to a circle, if it is not already in that shape. The
	radius of the resulting circle is compared to the maximum horizontal		radius of the resulting circle is compared to the maximum horizontal
	uncertainty.		uncertainty.
	Vertical uncertainty is evaluated for shapes that contain altitude		Vertical uncertainty is evaluated for shapes that contain altitude
	uncertainty. The value used for evaluating vertical uncertainty		uncertainty. The value used for evaluating vertical uncertainty
	depends on the shape type: the vertical axis value for the Ellipsoid		depends on the shape type: the vertical axis value for the Ellipsoid
	shape; the radius of the Sphere shape; half the height of the Prism		shape; the radius of the Sphere shape; half the height of the Prism
	shape.		shape.
	The LS MAY use location quality parameters to alter the way that it		The LS MAY use location quality parameters to alter the way that it
	generates location information and to provide location information		generates location information and to provide location information
	that more closely matches what is requested. If maximum value is		that more closely matches what is requested. If maximum value is
	provided for vertical uncertainty, is is RECOMMENDED that the LS		provided for vertical uncertainty, it is RECOMMENDED that the LS
	provide a location estimate that includes altitude and altitude		provide a location estimate that includes altitude and altitude
	uncertainty. It is RECOMMENDED that the LS provide location		uncertainty. It is RECOMMENDED that the LS provide location
	information at the requested confidence, if possible.		information at the confidence included in the request, if possible
			and if the location information is not significantly degraded by any
			scaling that might be required to do this.
	3.1.2. Required Civic Elements		3.1.2. Required Civic Elements
	The "requiredCivic" element represents the requirements of an LR for		The "requiredCivic" element represents the requirements of an LR for
	uncertainty in civic address information. An LR can specify the		civic address information. An LR can specify the address elements
	address elements that need to be present in the civic address in		that need to be present in the civic address in order for the
	order for the location information to meet their quality		location information to meet their quality requirements.
	requirements.
	The "requiredCivic" element contains a whitespace-separated list of		The "requiredCivic" element contains a whitespace-separated list of
	element names. These can be interpreted as XPath		element names. These can be interpreted as XPath
	[W3C.REC-xpath-19991116] expressions that are evaluated in the		[W3C.REC-xpath-19991116] expressions that are evaluated in the
	context of the "civicAddress" element		context of the "civicAddress" element [RFC5139]. These XPath
	[I-D.ietf-geopriv-revised-civic-lo]. These XPath statements are		statements are restricted to use of qualified names only (using the
	restricted to use of qualified names only (using the response		response document namespace context) and the "/" separator; that is,
	document namespace context) and the "/" separator. All child nodes		the only permitted axis is the "child::" axis. All child nodes of
	of elements (including attributes and textual content) are treated as		elements (including attributes and textual content) are treated as
	belonging to an element.		belonging to an element.
	Figure 3 shows an example request where an LR requires country, state		Figure 3 shows an example request where an LR requires country, state
	(or equivalent) and post code civic address elements in the location		(or equivalent) and post code civic address elements in the location
	information provided by the LS.		information provided by the LS.
	<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">		<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
	<requiredCivic		<requiredCivic
	xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	ca:country ca:A1 ca:PC		ca:country ca:A1 ca:PC
	</requiredCivic>		</requiredCivic>
	</quality>		</quality>
	Figure 3		Figure 3: Example Specifying Required Civic Address Fields
			Note that this does not force the LS to restrict civic address
			information to the indicated fields. Additional fields MAY be
			provided.
	3.1.3. Maximum Age		3.1.3. Maximum Age
	Where location information is stored or cached, an LR can specify how		Where location information is stored or cached, an LR can specify a
	long since the information. This is particularly important if		limit on the age of this information. This is particularly important
	location information is generated in advance. The "age" of location		if location information is generated in advance. The "age" of
	information is the taken as the time interval between the location		location information is indicated by the the "timestamp" element in
	information timestamp (the "timestamp" element in the PIDF tuple) and		the PIDF tuple. The age parameter specifies the minimum value for
	the time that the request is received by the LS.		this field; that is, the oldest location information that is
			acceptable.
	Location information that has greater age than requested SHOULD		Location information that has greater age than requested SHOULD
	either be determined anew, or checked so that the timestamp can be		either be determined anew, or checked so that the timestamp can be
	updated. If this value is set to zero (i.e. "PT0S"), stored		updated. A value of "now" can be used to indicate that stored
	location information cannot be used.		location information is not acceptable to the LR.
	3.2. Location Quality Indication		3.2. Location Quality Indication
	The "qualityInd" element contains a list of the quality constraints		The "qualityInd" element is used in responses to indicate which of
	that the resulting location information meets.		the location quality constraints from a request were met. The
			"qualityInd" element contains a list of the quality constraints that
			the accompanying location information meets.
	The list of constraints is represented as a whitespace-separated list		The list of constraints is represented as a whitespace-separated list
	of element names. These can be interpreted as XPath		of element names. These can be interpreted as XPath
	[W3C.REC-xpath-19991116] expressions that are evaluated in the		[W3C.REC-xpath-19991116] expressions that are evaluated in the
	context of the original location quality request. These statements		context of the original location quality request. These statements
	follow the same constraints as the list of elements in Section 3.1.2.		follow the same constraints as the list of elements in Section 3.1.2.
	Where elements are nested, such as the "maxUncertainty" element, the		Where elements are nested, such as the "maxUncertainty" element, the
	outer element can be included to indicate an entire constraint is		outer element can be included to indicate an entire constraint is
	met; or, each individual child element can be identified. Two		met; or, each individual child element can be identified. Two
	equivalent indications are shown in Figure 4.		equivalent indications are shown in Figure 4.
	<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">		<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
	maxUncertainty		maxUncertainty
	</qualityInd>		</qualityInd>
	<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">		<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
	maxUncertainty/horizontal maxUncertainty/vertical		maxUncertainty/horizontal maxUncertainty/vertical
	</qualityInd>		</qualityInd>
	Figure 4		Figure 4: Equivalent Quality Indications
	A LS that is unable to determine if a constraint MUST either omit the		A LS that is unable to determine if a constraint MUST either omit the
	quality indication, or indicate that the constraint was not met.		quality indication, or indicate that the constraint was not met.
	Two special values are added to the quality indication element for		Two special values are added to the quality indication element for
	convenience. The value "##all" indicates that all quality		convenience. The value "##all" indicates that all quality
	constraints were met (including any extensions). The value "##none"		constraints were met (including any extensions). The value "##none"
	indicates that none of the constraints were met.		indicates that none of the constraints were met.
	4. Location Quality Schema		4. Location Quality Schema
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	</xs:schema>		</xs:schema>
	5. Security Considerations		5. Security Considerations
	This document does not introduce any security considerations.		This document does not introduce any security considerations.
	[[Editor's Note: Please let us know if you can think of some.]]		[[Editor's Note: Please let us know if you can think of some.]]
	6. IANA Considerations		6. IANA Considerations
			This section registers a namespace and schema for the location
			quality objects.
	6.1. URN Sub-Namespace Registration for		6.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:lq		urn:ietf:params:xml:ns:geopriv:lq
	This section registers a new XML namespace,		This section registers a new XML namespace,
	"urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in		"urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:ns:geopriv:lq		URI: urn:ietf:params:xml:ns:geopriv:lq
	Registrant Contact: IETF, GEOPRIV working group,		Registrant Contact: IETF, GEOPRIV working group,
	(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).		(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">		<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>		<head>
	<title>HELD Location Quality</title>		<title>Location Quality</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for HELD Location Quality</h1>		<h1>Namespace for Location Quality</h1>
	<h2>urn:ietf:params:xml:ns:geopriv:lq</h2>		<h2>urn:ietf:params:xml:ns:geopriv:lq</h2>
	[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX		[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
	with the RFC number for this specification.]]		with the RFC number for this specification.]]
	<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>		<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	6.2. XML Schema Registration for Measurement Schema		6.2. XML Schema Registration for Location Quality Schema
	This section registers an XML schema as per the guidelines in		This section registers an XML schema as per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:schema:geopriv:lq		URI: urn:ietf:params:xml:schema:geopriv:lq
	Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),		Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
	Martin Thomson (martin.thomson@andrew.com).		Martin Thomson (martin.thomson@andrew.com).
	Schema: The XML for this schema can be found in Section 4 of this		Schema: The XML for this schema can be found in Section 4 of this
	skipping to change at page 15, line 15 ¶		skipping to change at page 16, line 15 ¶
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
			[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
			Format for Presence Information Data Format Location
			Object (PIDF-LO)", RFC 5139, February 2008.
	[I-D.ietf-geopriv-http-location-delivery]		[I-D.ietf-geopriv-http-location-delivery]
	Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,		Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
	"HTTP Enabled Location Delivery (HELD)",		"HTTP Enabled Location Delivery (HELD)",
	draft-ietf-geopriv-http-location-delivery-03 (work in		draft-ietf-geopriv-http-location-delivery-07 (work in
	progress), November 2007.		progress), April 2008.
	[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-00 (work in progress),		draft-thomson-geopriv-uncertainty-00 (work in progress),
	November 2007.		November 2007.
	7.2. Informative References		7.2. Informative References
	[W3C.REC-xpath-19991116]		[W3C.REC-xpath-19991116]
	DeRose, S. and J. Clark, "XML Path Language (XPath)		Clark, J. and S. DeRose, "XML Path Language (XPath)
	Version 1.0", World Wide Web Consortium		Version 1.0", World Wide Web Consortium
	Recommendation REC-xpath-19991116, November 1999,		Recommendation REC-xpath-19991116, November 1999,
	<http://www.w3.org/TR/1999/REC-xpath-19991116>.		<http://www.w3.org/TR/1999/REC-xpath-19991116>.
	[I-D.ietf-geopriv-revised-civic-lo]
	Thomson, M. and J. Winterbottom, "Revised Civic Location
	Format for PIDF-LO",
	draft-ietf-geopriv-revised-civic-lo-07 (work in progress),
	December 2007.
	[I-D.busin-geopriv-location-qos-req]		[I-D.busin-geopriv-location-qos-req]
	Busin, A., Jin, Y., Mosmondor, M., and S. Loreto,		Busin, A., Jin, Y., Mosmondor, M., and S. Loreto,
	"Requirements for a Location Quality of Service (QoS)		"Requirements for a Location Quality of Service (QoS)
	Information Object",		Information Object",
	draft-busin-geopriv-location-qos-req-01 (work in		draft-busin-geopriv-location-qos-req-01 (work in
	progress), November 2007.		progress), November 2007.
	[I-D.ietf-geopriv-l7-lcp-ps]		[I-D.ietf-geopriv-l7-lcp-ps]
	Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol; Problem Statement and		Location Configuration Protocol; Problem Statement and
	Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in		Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
	progress), November 2007.		progress), March 2008.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[GeoShape]		[GeoShape]
	Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape		Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
	Application Schema for use by the Internet Engineering		Application Schema for use by the Internet Engineering
	Task Force (IETF)", Candidate OpenGIS Implementation		Task Force (IETF)", Candidate OpenGIS Implementation
	Specification 06-142r1, Version: 1.0, April 2007.		Specification 06-142r1, Version: 1.0, April 2007.
	skipping to change at page 18, line 7 ¶		skipping to change at page 19, line 7 ¶
	PO Box U40		PO Box U40
	Wollongong University Campus, NSW 2500		Wollongong University Campus, NSW 2500
	AU		AU
	Phone: +61 2 4221 2938		Phone: +61 2 4221 2938
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@andrew.com
	URI: http://www.andrew.com/		URI: http://www.andrew.com/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 18, line 44 ¶		skipping to change at line 627 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 39 change blocks.
	88 lines changed or deleted		112 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/