< draft-mahy-geopriv-loc-filters-00.txt		draft-mahy-geopriv-loc-filters-01.txt >
	WG R. Mahy		WG R. Mahy
	Internet-Draft SIP Edge LLC		Internet-Draft Plantronics
	Expires: April 4, 2006 Oct 2005		Expires: September 6, 2006 March 5, 2006
	A Document Format for Filtering and Reporting Location Notications in		A Document Format for Filtering and Reporting Location Notications in
	PIDF-LO		PIDF-LO
	draft-mahy-geopriv-loc-filters-00.txt		draft-mahy-geopriv-loc-filters-01.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 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 April 4, 2006.		This Internet-Draft will expire on September 6, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes filters which limit asynchronous location		This document describes filters which limit asynchronous location
	notifications to compelling events. The resulting location		notifications to compelling events. The resulting location
	information is conveyed in existing location formats wrapped in		information is conveyed in existing location formats wrapped in
	GEOPRIV privacy extensions to the Presence Information Document		GEOPRIV privacy extensions to the Presence Information Document
	Format (PIDF-LO). Location disclosure is limited to voluntary		Format (PIDF-LO). Location disclosure is limited to voluntary
	disclosure by a notifier that possesses credentials for the named		disclosure by a notifier that possesses credentials for the named
	resource.		resource.
	Table of Contents		Table of Contents
	1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definition of Location Filter Format . . . . . . . . . . . . . 3		3. Definition of Location Filter Format . . . . . . . . . . . . . 3
	3.1 XML Schema for filter format . . . . . . . . . . . . . . . 11		3.1 Horizontal and Vertical Movement . . . . . . . . . . . . . 4
	4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 11		3.2 Changes in value . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		3.3 Containment Within a Region . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		3.4 XML Schema for filter format . . . . . . . . . . . . . . . 9
			4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 10
			5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.1 MIME Registration for		6.1 MIME Registration for
	application/location-delta-filter+xml . . . . . . . . . . 14		application/location-delta-filter+xml . . . . . . . . . . 13
	6.2 URN Sub-Namespace Registration for		6.2 URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 14		urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13
	6.3 Schema Registration For location-filter . . . . . . . . . 15		6.3 Schema Registration For location-filter . . . . . . . . . 14
	6.4 URN Sub-Namespace Registration for		6.4 URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 15		urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 14
	6.5 Schema Registration For containment . . . . . . . . . . . 16		6.5 Schema Registration For containment . . . . . . . . . . . 15
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 16		8.1 Normative References . . . . . . . . . . . . . . . . . . . 15
	8.2 Informational References . . . . . . . . . . . . . . . . . 17		8.2 Informational References . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . . 17
	1. Conventions		1. Conventions
	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 [2].		document are to be interpreted as described in RFC-2119 [2].
	2. Overview		2. Overview
	Conveying static location in PIDF-LO [1] bodies is straightforward.		Conveying static location in PIDF-LO [1] bodies is straightforward.
	However the difficult part about asynchronous notification of		However the difficult part about asynchronous notification of
	location information is that many forms of location are measured as a		location information is that many forms of location are measured as a
	continous gradient. Unlike notications using discreet quanties, it		continuous gradient. Unlike notifications using discreet quantities,
	is difficult to know when a change in location is large enough to		it is difficult to know when a change in location is large enough to
	warrant notifications. Moreover, different applications require a		warrant a notification. Moreover, different applications require a
	wide variety of location resolutions. Any optimization made for one		wide variety of location resolutions. Any optimization made for one
	application would ultimately result in wasteful polling or a sluggish		application would ultimately result in wasteful polling or a sluggish
	user interface for other applications.		user interface for other applications.
	The mechanism described here defines filters in XML [3] documents		The mechanism described here defines filters in XML [3] documents
	which limit location notification to events which are of relevance to		which limit location notification to events which are of relevance to
	the subscriber. These filters persist until they are changed with a		the subscriber. These filters persist until they are changed with a
	replacement filter.		replacement filter.
	In addition to the relevant filters, this document also defines a new		In addition to the relevant filters, this document also defines a new
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	that the resource is inside or outside of a container region.		that the resource is inside or outside of a container region.
	3. Definition of Location Filter Format		3. Definition of Location Filter Format
	The granularity of notifications necessary for various geographic		The granularity of notifications necessary for various geographic
	location applications varies dramatically. The subscriber should be		location applications varies dramatically. The subscriber should be
	able to get asynchronous notifications with appropriate granularity		able to get asynchronous notifications with appropriate granularity
	and accuracy, without having to poll or flood the network with		and accuracy, without having to poll or flood the network with
	notifications which are not important to the application.		notifications which are not important to the application.
	Notifications should only happen when the notification would be		Notifications should only happen when the notification would be
	considered an Interesting Event to the subscriber. Subscriptions to		considered an Interesting Event to the subscriber. This section of
	this event package contain a filter document in the XML document		this document defines an XML filter format to describe interesting
	format defined in this section. The terminal elements in this format		conditions or events. The terminal elements in this format are
	are defined in terms of existing Geographic Markup Language (GML) [8]		defined in terms of existing Geographic Markup Language (GML) [9]
	data types.		data types.
	The notifications are in PIDF-LO (by default) or any other format
	acceptable to both the subscriber and notifier. The selection of		This document also defines a MIME type for this location filter
	a subset of GML or specific location format capabilities contained		format: application/location-delta-filter+xml.
	in a PIDF-LO body is a generic issue for the GEOPRIV Working Group
	to define, and is out of the scope of this document.
	This document defines the following as an initial list of Interesting		This document defines the following as an initial list of Interesting
	Events:		Events:
	1. the resource moves more than a specific distance horizontally or		1. the resource moves more than a specific distance horizontally or
	vertically since the last notification		vertically since the last notification
	2. the resource exceeds a specific speed		2. the resource exceeds a specific speed
	3. the resource enters or exits one or more GML objects (for		3. the resource enters or exits one or more GML objects (for
	example, a set of 2-dimensional or 3-dimensional regions)		example, a set of 2-dimensional or 3-dimensional regions)
	included or referenced in the filter.		included or referenced in the filter.
	4. one or more of the values of the specified address labels has		4. one or more of the values of the specified address labels has
	changed for the resource (for example, the A1 value of the		changed for the resource (for example, the A1 value of the
	civilAddress has changed from California to Nevada)		civilAddress has changed from California to Nevada)
	This specification makes use of XML namespaces [5] for identifying		This specification makes use of XML namespaces [5] for identifying
	location filter documents and document fragments. The namespace URI		location filter documents and document fragments. The namespace URI
	for elements defined by this specification is a URN [9], using the		for elements defined by this specification is a URN [10], using the
	namespace identifier 'ietf' defined by [10] and extended by [11].		namespace identifier 'ietf' defined by [11] and extended by [12].
	This URN is:		This URN is:
	urn:ietf:params:xml:ns:location-filter		urn:ietf:params:xml:ns:location-filter
	The filter format starts with a top-level XML element called		The filter format starts with a top-level XML element called
	"<location-filter>", which contains one or more filter events. The		"<location-filter>", which contains one or more filter events. The
	semantics of multiple elements inside a location-filter is a logical		semantics of multiple elements inside a location-filter is a logical
	OR. In other words, if any of the individual filter events occurs,		OR. In other words, if any of the individual filter events occurs,
	the event satisfies the location-filter and triggers a notification.		the event satisfies the location-filter and triggers a notification.
			3.1 Horizontal and Vertical Movement
	The movedHoriz and movedVert filter events each indicate a minimum		The movedHoriz and movedVert filter events each indicate a minimum
	horizontal motion or vertical distance (respectively) that the		horizontal motion or vertical distance (respectively) that the
	resource must have moved from the location of the resource when the		resource must have moved from the location of the resource when the
	last notification was sent in order to trigger this event. The		last notification was sent in order to trigger this event. The
	distance is measured absolutely from the point of last notification		distance is measured absolutely from the point of last notification
	rather than in terms of cumulative motion (For example, someone		rather than in terms of cumulative motion (For example, someone
	pacing inside a room will not trigger an event if the trigger		pacing inside a room will not trigger an event if the trigger
	threshold is slightly larger than the room.) Each of these events		threshold is slightly larger than the room.) Each of these events
	can only appear once in a location-filter. These events have an		can only appear once in a location-filter. These events have an
	attribute "uom" (for "units of measure"), which indicates the units		attribute "uom" (for "units of measure"), which indicates the units
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 8 ¶
	This filter measures the horizontal component of speed in any		This filter measures the horizontal component of speed in any
	direction. It does not measure velocity. Note also that there is		direction. It does not measure velocity. Note also that there is
	no corresponding event triggered when speed drops below a		no corresponding event triggered when speed drops below a
	threshold.		threshold.
	Below are some examples. In the first example if the resource moves		Below are some examples. In the first example if the resource moves
	20m in the x,y direction or 3m in the z direction, send a		20m in the x,y direction or 3m in the z direction, send a
	notification:		notification:
	<location-filter>		<location-filter>
	<movedHoriz uom="#meters">20</movedHoriz>		<movedHoriz uom="urn:ogc:def:uom:EPSG::9001">20</movedHoriz>
	<movedVert uom="#meters">3</movedVert>		<movedVert uom="urn:ogc:def:uom:EPSG::9001">3</movedVert>
	</location-filter>		</location-filter>
	If the resource exceeds 3 meters per second (10.8 km/h), send a		If the resource exceeds 3 meters per second (10.8 km/h), send a
	notification:		notification:
	<location-filter>		<location-filter>
	<speedExceeds uom="#mps">3</speedExceeds>		<speedExceeds uom="#mps">3</speedExceeds>
	</location-filter>		</location-filter>
			3.2 Changes in value
	The valueChanges filter event contains a string which is interpreted		The valueChanges filter event contains a string which is interpreted
	as an XPath [6] expression evaluated within the context of the		as an XPath [6] expression evaluated within the context of the
	location-info element of the PIDF-LO document which would be		location-info element of the PIDF-LO document which would be
	generated by the notification. The XPath expression MUST evaluate to		generated by the notification. The XPath expression MUST evaluate to
	only a single Xpath node. If the value of any of the elements in the		only a single Xpath node. If the value of any of the elements in the
	resulting node changes, then the filter event is triggered. Note		resulting node changes, then the filter event is triggered. Note
	that the value of the resulting node changes if any of those nodes or		that the value of the resulting node changes if any of those nodes or
	subnodes transitions from having a value to having no value or vice		subnodes transitions from having a value to having no value or vice
	versa. A location-filter may contain multiple valueChanges filters.		versa. A location-filter may contain multiple valueChanges filters.
			Note that the example below needs to be updated to use the revised
			civic location format.
	For example, given the following logical PIDF-LO document, If the		For example, given the following logical PIDF-LO document, If the
	state (A1), county (A2), city (A3), or postal code (PC) changes, send		state (A1), county (A2), city (A3), or postal code (PC) changes, send
	a notification:		a notification:
	PIDF-LO Location Document:		PIDF-LO Location Document:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
	entity="pres:geotarget@example.com">		entity="pres:geotarget@example.com">
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	Filter Document:		Filter Document:
	<location-filter		<location-filter
	xmlns="urn:ietf:params:xml:ns:location-filter"		xmlns="urn:ietf:params:xml:ns:location-filter"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc">		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc">
	<valueChanges>cl:civilAddress/cl:A1</valueChanges>		<valueChanges>cl:civilAddress/cl:A1</valueChanges>
	<valueChanges>cl:civilAddress/cl:A2</valueChanges>		<valueChanges>cl:civilAddress/cl:A2</valueChanges>
	<valueChanges>cl:civilAddress/cl:A3</valueChanges>		<valueChanges>cl:civilAddress/cl:A3</valueChanges>
	<valueChanges>cl:civilAddress/cl:PC</valueChanges>		<valueChanges>cl:civilAddress/cl:PC</valueChanges>
	</location-filter>		</location-filter>
	Finally, the "enterOrExit" filter event is triggered when the		3.3 Containment Within a Region
	resource enters or exits a named 2-dimensional or 3-dimensional
	region or list of regions corresponding to a GML feature. These
	regions can be defined using inline snippets of GML, or externally
	referenced using a URI (Uniform Resource Identifier). Notifiers
	which support this document MUST be able to support 2-dimensional
	regions and lists of regions, for which the regions can be defined in
	terms of the GML extentOf a Polygon defined using an exterior
	LinearRing object. These Polygons are defined using the hierarcy in
	the figure below.
	Hierarchy for 2-D Hierarchy for 3-D
	Objects Objects
	extentOf Solid
	Polygon exterior
	exterior Surface
	LinearRing patches
	posList Polygon
	...
	Polygon
	Similarly, Notifiers MUST be able to support 3-dimensional regions		Finally, the "enterOrExit" filter event is satisfied when the
	which can be defined as a fixed height vertical projection of such a		resource enters or exits a named 2-dimensional or 3-dimensional
	2-dimensional Polygon, and lists thereof. Specifically, these are		region described by one of the shapes defined in [8]. These regions
	GML Solids defined in terms of an exterior Surface of polygonal		can be defined using inline snippets of GML, or externally referenced
	patches, such that all included Polygons are either parallel		using a URI (Uniform Resource Identifier).
	(horizontal) or perpedicular (vertical) to the geoid.		These regions need a unique name or identifier so location with
			respect to these regions can be described later (for example in a
			notification). These regions are currently described as GML
			Features so they can be named with a GML Name. Ideally each
			region could be described instead as a GML geometry with some
			associated name or identifier.
	The posList for any 2-dimensional region MUST be defined using the		Any 2-dimensional region MUST be defined using the EPSG 4326
	EPSG 4326 coordinate reference system. The posList for any		coordinate reference system. Any 3-dimensional region MUST be
	3-dimensional region MUST be defined using the EPSG 4979 coordinate		defined using the EPSG 4979 coordinate reference system. A location-
	reference system. A location-filter can contain more than one		filter can contain more than one enterOrExit filter event.
	enterOrExit filter event.
	Notifiers MAY support other more complex geometries or additional		Notifiers MAY support other more complex geometries or additional
	coordinate reference systems. How the Subscriber negotiates		coordinate reference systems. How the Subscriber negotiates
	support for more complex geometries or reference systems is out of		support for more complex geometries or reference systems is out of
	the scope of this document.		the scope of this document.
	Likewise, this document does not describe how a subscriber		Likewise, this document does not describe how a subscriber
	discovers the existence of externally referenced features. This		discovers the existence of externally referenced features. This
	topic is out of scope of this document.		topic is out of scope of this document.
	In most cases Subscribers that use location filters based on		In most cases Subscribers that use location filters based on
	enterOrExit events are especially interested in the resource's		enterOrExit events are especially interested in the resource's
	skipping to change at page 8, line 11 ¶		skipping to change at page 7, line 43 ¶
	For example, if the resource enters or exits Building 10 (which is		For example, if the resource enters or exits Building 10 (which is
	defined by specific 2-D or 3-D rectangular coordinates), send a		defined by specific 2-D or 3-D rectangular coordinates), send a
	notification:		notification:
	Version in 2-Dimensions:		Version in 2-Dimensions:
	<location-filter>		<location-filter>
	<enterOrExit>		<enterOrExit>
	<my:Building>		<my:Building>
	<gml:name>Building 10</gml:name>		<gml:name>Building 10</gml:name>
	<gml:extentOf>		<gml:extentOf>
	<gml:Polygon>		<gml:Polygon
			srsName="urn:ogc:def:crs:EPSG::4326"
			xmlns:gml="http://www.opengis.net/gml">
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	<gml:posList		<gml:posList
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">		37.41188 -121.93243
	37.41188 -121.93243 0		37.41142 -121.93243
	37.41188 -121.93132 0		37.41142 -121.93132
	37.41142 -121.93132 0		37.41188 -121.93132
	37.41142 -121.93242 0		37.41188 -121.93243
	37.41188 -121.93243 0
	</gml:posLis>		</gml:posLis>
	</gml:LinearRing>		</gml:LinearRing>
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	</gml:extentOf>		</gml:extentOf>
	</my:Building>		</my:Building>
	</enterOrExit>		</enterOrExit>
	</location-filter>		</location-filter>
	Version in 3-Dimensions:		Version in 3-Dimensions:
	<location-filter>		<location-filter>
	<enterOrExit>		<enterOrExit>
	<my:Building>		<my:Building>
	<gml:name>Building 10</gml:name>		<gml:name>Building 10</gml:name>
	<gml:Solid>		<gs:Prism
	<gml:exterior>		srsName="urn:ogc:def:crs:EPSG::4979"
	<gml:Surface>		xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
	<gml:patches>		xmlns:gml="http://www.opengis.net/gml">
	<gml:Polygon> <!-- floor -->		<gs:base>
	<gml:exterior>		<gml:Polygon>
	<gml:LinearRing>		<gml:exterior>
	<gml:posList		<gml:LinearRing>
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">		<gml:posList>
	37.41188 -121.93243 0		37.41188 -121.93243 0
	37.41188 -121.93132 0		37.41142 -121.93242 0
	37.41142 -121.93132 0		37.41142 -121.93132 0
	37.41142 -121.93242 0		37.41188 -121.93132 0
	37.41188 -121.93243 0		37.41188 -121.93243 0
	</gml:posLis>		</gml:posList>
	</gml:LinearRing>		</gml:LinearRing>
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	<gml:Polygon> <!-- north wall -->		</gs:base>
	<gml:exterior>		<gs:height uom="urn:ogc:def:uom:EPSG::9001">
	<gml:LinearRing>		24
	<gml:posList		</gs:height>
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">		</gs:Prism>
	37.41188 -121.93243 0
	37.41188 -121.93243 0
	37.41188 -121.93132 25
	37.41188 -121.93132 25
	37.41188 -121.93243 0
	</gml:posLis>
	</gml:LinearRing>
	</gml:exterior>
	</gml:Polygon>
	<gml:Polygon> <!-- east wall -->
	<gml:exterior>
	<gml:LinearRing>
	<gml:posList
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">
	37.41188 -121.93132 0
	37.41188 -121.93132 25
	37.41142 -121.93132 25
	37.41142 -121.93132 0
	37.41188 -121.93132 0
	</gml:posLis>
	</gml:LinearRing>
	</gml:exterior>
	</gml:Polygon>
	<gml:Polygon> <!-- south wall -->
	<gml:exterior>
	<gml:LinearRing>
	<gml:posList
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">
	37.41142 -121.93132 0
	37.41142 -121.93132 25
	37.41142 -121.93242 25
	37.41142 -121.93242 0
	37.41142 -121.93132 0
	</gml:posLis>
	</gml:LinearRing>
	</gml:exterior>
	</gml:Polygon>
	<gml:Polygon> <!-- west wall -->
	<gml:exterior>
	<gml:LinearRing>
	<gml:posList
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">
	37.41142 -121.93243 0
	37.41142 -121.93243 25
	37.41188 -121.93243 25
	37.41188 -121.93243 0
	37.41142 -121.93243 0
	</gml:posLis>
	</gml:LinearRing>
	</gml:exterior>
	</gml:Polygon>
	<gml:Polygon> <!-- roof -->
	<gml:exterior>
	<gml:LinearRing>
	<gml:posList
	srsName="http://www.opengis.net/gml/srs/epsg.xml/#4979">
	37.41188 -121.93243 25
	37.41188 -121.93132 25
	37.41142 -121.93132 25
	37.41142 -121.93242 25
	37.41188 -121.93243 25
	</gml:posLis>
	</gml:LinearRing>
	</gml:exterior>
	</gml:Polygon>
	</gml:patches>
	</gml:Surface>
	</gml:exterior>
	</gml:Solid>
	</my:Building>		</my:Building>
	</enterOrExit>		</enterOrExit>
	</location-filter>		</location-filter>
	If the resource enters or exits either the parking garage or any of		If the resource enters or exits either the parking garage or any of
	the conference rooms (both of which are externally defined), send a		the conference rooms (both of which are externally defined), send a
	notification:		notification:
	<location-filter>		<location-filter>
	<enterOrExit>		<enterOrExit>
	<my:ParkingGarage		<my:ParkingGarage
	xlink:href="http://server.example.com/loc-defs/bldg-mgr/parking"/>		xlink:href="http://server.example.com/loc-defs/bldg-mgr/parking"/>
	</enterOrExit>		</enterOrExit>
	<enterOrExit>		<enterOrExit>
	<my:ConferenceRooms		<my:ConferenceRooms
	xlink:href="http://server.example.com/loc-defs/userdef/confrooms"/>		xlink:href="http://server.example.com/loc-defs/userdef/confrooms"/>
	</enterOrExit>		</enterOrExit>
	</location-filter>		</location-filter>
	3.1 XML Schema for filter format		3.4 XML Schema for filter format
	The XML Schema for this format is defined below.		The XML Schema for this format is defined below.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:location-filter"		targetNamespace="urn:ietf:params:xml:ns:location-filter"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:gml="http://www.opengis.net/gml">		xmlns:gml="http://www.opengis.net/gml">
	<xs:element name="location-filter">		<xs:element name="location-filter">
	skipping to change at page 11, line 32 ¶		skipping to change at page 9, line 43 ¶
	<xs:element name="speedExceeds" type="gml:MeasureType"		<xs:element name="speedExceeds" type="gml:MeasureType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- this type needs to hold an XPath statement -->		<!-- this type needs to hold an XPath statement -->
	<xs:element name="valueChanges" type="xs:string"		<xs:element name="valueChanges" type="xs:string"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="enterOrExit" type="gml:FeaturePropertyType"		<xs:element name="enterOrExit" type="gml:FeaturePropertyType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<!-- Do we want to incldue this to allow new filters? -->		<!-- Do we want to include this to allow new filters? -->
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	4. Containment schema		4. Containment schema
	This section describes the schema for describing the resource's		This section describes a schema for describing the resource's
	location relative to a region or list of regions which might contain		location relative to a region or list of regions which might contain
	the resource. (These regions can be defined dynamically in an		the resource. (These regions can be defined dynamically in an
	"enterOrExit" element in a subscription filter, or defined on the		"enterOrExit" element in a subscription filter, or defined on the
	notifier using some out-of-band mechanism.) The "pidfResource"		notifier using some out-of-band mechanism.) The "pidfResource"
	element is placed inside the location-info element in a PIDF-LO		element is placed inside the location-info element in a PIDF-LO
	document. The pidfResource element can contain zero or more		document. The pidfResource element can contain zero or more
	"containment" elements. Each containment element has a GML Feature		"containment" elements. Each containment element has a GML Feature
	sub-element (of type "FeaturePropertyType") and a mandatory attribute		sub-element (of type "FeaturePropertyType") and a mandatory attribute
	which specifies if the PIDF resource is inside or outside of the		which specifies if the PIDF resource is inside or outside of the
	feature, or if the position of the resource with respect to the		feature, or if the position of the resource with respect to the
	region or region list is undefined. If the subscriber is not		region or region list is undefined.
	authorized to know the relative position, the notifier MUST NOT		In a future version of this specification, the GML Feature can
	reveal this private information. The RECOMMENDED way to prevent the		become a reference to a more preferable name or identifier type.
	subscriber from seeing private location data of this type is to		The GML Feature type is only used because it includes a name to
	return a containment element whose position attribute is "undefined".		reference it.
			If the subscriber is not authorized to know the relative position,
			the notifier MUST NOT reveal this private information. The
			RECOMMENDED way to prevent the subscriber from seeing private
			location data of this type is to return a containment element whose
			position attribute is "undefined". Note that in some cases, the
			containment information may be more interesting than the actual raw
			location. It is not necessary to convey a concrete civic or geo
			location in a PIDF-LO if the subscriber is only interested in or
			authorized to see the containment status.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:containment"		targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:pr="urn:ietf:params:xml:ns:pidf:geopriv10:containment" >		xmlns:pr="urn:ietf:params:xml:ns:pidf:geopriv10:containment" >
	<xs:element name="pidfResource">		<xs:element name="pidfResource">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	skipping to change at page 14, line 43 ¶		skipping to change at page 13, line 43 ¶
	1. Magic number(s): N/A		1. Magic number(s): N/A
	2. File extension(s): N/A		2. File extension(s): N/A
	3. Macintosh file type code: N/A		3. Macintosh file type code: N/A
	6.2 URN Sub-Namespace Registration for		6.2 URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:location-filter		urn:ietf:params:xml:ns:location-filter
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	[11].		[12].
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:location-filter.		urn:ietf:params:xml:ns:location-filter.
	Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,		Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,
	as delegated by the IESG <iesg@ietf.org>.		as delegated by the IESG <iesg@ietf.org>.
	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"
	skipping to change at page 15, line 27 ¶		skipping to change at page 14, line 27 ¶
	<body>		<body>
	<h1>Namespace for PIDF-LO Location Filters</h1>		<h1>Namespace for PIDF-LO Location Filters</h1>
	<h2>urn:ietf:params:xml:ns:location-filter</h2>		<h2>urn:ietf:params:xml:ns:location-filter</h2>
	<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>		<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	6.3 Schema Registration For location-filter		6.3 Schema Registration For location-filter
	This specification registers a schema, as per the guidelines in in		This specification registers a schema, as per the guidelines in [12].
	[11].
	URI: please assign.		URI: please assign.
	Registrant Contact: IETF, GEOPRIV Working Group		Registrant Contact: IETF, GEOPRIV Working Group
	(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).		(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).
	XML: The XML can be found as the sole content of Section 3.1.		XML: The XML can be found as the sole content of Section 3.4.
	6.4 URN Sub-Namespace Registration for		6.4 URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:pidf:geopriv10:containment		urn:ietf:params:xml:ns:pidf:geopriv10:containment
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	[11].		[12].
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:pidf:geopriv10:containment.		urn:ietf:params:xml:ns:pidf:geopriv10:containment.
	Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,		Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,
	as delegated by the IESG <iesg@ietf.org>.		as delegated by the IESG <iesg@ietf.org>.
	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">
	skipping to change at page 16, line 25 ¶		skipping to change at page 15, line 25 ¶
	<body>		<body>
	<h1>Namespace for PIDF-LO location containment elements</h1>		<h1>Namespace for PIDF-LO location containment elements</h1>
	<h2>urn:ietf:params:xml:ns:pidf:geopriv10:containment</h2>		<h2>urn:ietf:params:xml:ns:pidf:geopriv10:containment</h2>
	<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>		<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	6.5 Schema Registration For containment		6.5 Schema Registration For containment
	This specification registers a schema, as per the guidelines in in		This specification registers a schema, as per the guidelines in [12].
	[11].
	URI: please assign.		URI: please assign.
	Registrant Contact: IETF, GEOPRIV Working Group		Registrant Contact: IETF, GEOPRIV Working Group
	(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.orgw).		(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).
	XML: The XML can be found as the sole content of Section 4.		XML: The XML can be found as the sole content of Section 4.
	7. Acknowledgments		7. Acknowledgments
	Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for		Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for
	their comments.		their comments.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format",		[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
	draft-ietf-geopriv-pidf-lo-03 (work in progress),		RFC 4119, December 2005.
	September 2004.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,		[3] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
	"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,		"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
	October 2000, <http://www.w3.org/TR/REC-xml>.		October 2000, <http://www.w3.org/TR/REC-xml>.
	[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML		[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
	Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,		Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
	<http://www.w3.org/TR/xmlschema-1/>.		<http://www.w3.org/TR/xmlschema-1/>.
	[5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",		[5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
	W3C REC-xml-names, January 1999,		W3C REC-xml-names, January 1999,
	<http://www.w3.org/TR/REC-xml-names>.		<http://www.w3.org/TR/REC-xml-names>.
	[6] Clark, J. and S. DeRose, "XML Path Language (XPath) Version		[6] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
	1.0", W3C Recommendation xpath, November 1999,		1.0", W3C Recommendation xpath, November 1999,
	<http://www.w3.org/TR/xpath>.		<http://www.w3.org/TR/xpath>.
	[7] Winterbottom, J., "GEOPRIV PIDF-LO Usage Clarification,		[7] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
	Considerations and Recommendations",		Considerations and Recommendations",
	draft-winterbottom-geopriv-pdif-lo-profile-00 (work in		draft-ietf-geopriv-pdif-lo-profile-02 (work in progress),
	progress), February 2005.		February 2006.
	[8] OpenGIS, "Open Geography Markup Language (GML) Implementation		[8] Thomson, M., "Geodetic Shapes for the Representation of
			Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-00
			(work in progress), February 2006.
			[9] OpenGIS, "Open Geography Markup Language (GML) Implementation
	Specification", OpenGIS OGC 02-023r4, January 2003,		Specification", OpenGIS OGC 02-023r4, January 2003,
	<http://www.opengis.org/techno/implementation.htm>.		<http://www.opengis.org/techno/implementation.htm>.
	8.2 Informational References		8.2 Informational References
	[9] Moats, R., "URN Syntax", RFC 2141, May 1997.		[10] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[10] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[11] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	August 1999.		August 1999.
	[11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	Author's Address		Author's Address
	Rohan Mahy		Rohan Mahy
	SIP Edge LLC		Plantronics
			345 Encincal Street
			Santa Cruz, CA
			USA
	Email: rohan@ekabal.com		Email: rohan@ekabal.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	skipping to change at page 18, line 41 ¶		skipping to change at page 17, line 41 ¶
	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 AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 41 change blocks.
	194 lines changed or deleted		131 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/