< draft-ietf-geopriv-pdif-lo-profile-13.txt		draft-ietf-geopriv-pdif-lo-profile-14.txt >
	Geopriv J. Winterbottom		Geopriv J. Winterbottom
	Internet-Draft M. Thomson		Internet-Draft M. Thomson
	Updates: 4119 (if approved) Andrew Corporation		Updates: 4119 (if approved) Andrew Corporation
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: March 21, 2009 Nokia Siemens Networks		Expires: May 29, 2009 Nokia Siemens Networks
	September 17, 2008		November 25, 2008
	GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations		GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
	draft-ietf-geopriv-pdif-lo-profile-13.txt		draft-ietf-geopriv-pdif-lo-profile-14
	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 36 ¶		skipping to change at page 1, line 36 ¶
	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 March 21, 2009.		This Internet-Draft will expire on May 29, 2009.
	Abstract		Abstract
	The Presence Information Data Format Location Object (PIDF-LO)		The Presence Information Data Format Location Object (PIDF-LO)
	specification provides a flexible and versatile means to represent		specification provides a flexible and versatile means to represent
	location information. There are, however, circumstances that arise		location information. There are, however, circumstances that arise
	when information needs to be constrained in how it is represented.		when information needs to be constrained in how it is represented.
	In these circumstances the range of options that need to be		In these circumstances the range of options that need to be
	implemented are reduced. There is growing interest in being able to		implemented are reduced. There is growing interest in being able to
	use location information contained in a PIDF-LO for routing		use location information contained in a PIDF-LO for routing
	applications. To allow successful interoperability between		applications. To allow successful interoperability between
	applications, location information needs to be normative and more		applications, location information needs to be normative and more
	tightly constrained than is currently specified in the RFC 4119		tightly constrained than is currently specified in the RFC 4119
	(PIDF-LO). This document makes recommendations on how to constrain,		(PIDF-LO). This document makes recommendations on how to constrain,
	represent and interpret locations in a PIDF-LO. It further		represent and interpret locations in a PIDF-LO. This further
	recommends a subset of GML that is mandatory to implement by		recommends a subset of Geography Markup Language (GML) 3.1.1 that is
	applications involved in location based routing.		mandatory to implement by applications involved in location based
			routing.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Using Location Information . . . . . . . . . . . . . . . . . . 6		3. Using Location Information . . . . . . . . . . . . . . . . . . 6
	3.1. Single Civic Location Information . . . . . . . . . . . . 9		3.1. Single Civic Location Information . . . . . . . . . . . . 9
	3.2. Civic and Geospatial Location Information . . . . . . . . 9		3.2. Civic and Geospatial Location Information . . . . . . . . 9
	3.3. Manual/Automatic Configuration of Location Information . . 10		3.3. Manual/Automatic Configuration of Location Information . . 10
	3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11		3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15		5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15
	5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16
	5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16		5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 18		5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 18
	5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 20		5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 21		5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 22		5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 22
	5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 24		5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 24
	5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 25		5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 25
	5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 27		5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 27
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 30		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1. Normative references . . . . . . . . . . . . . . . . . . . 33		9.1. Normative references . . . . . . . . . . . . . . . . . . . 32
	9.2. Informative References . . . . . . . . . . . . . . . . . . 33		9.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
	Intellectual Property and Copyright Statements . . . . . . . . . . 35		Intellectual Property and Copyright Statements . . . . . . . . . . 35
	1. Introduction		1. Introduction
	The Presence Information Data Format Location Object (PIDF-LO)		The Presence Information Data Format Location Object (PIDF-LO)
	[RFC4119] is the recommended way of encoding location information and		[RFC4119] is the recommended way of encoding location information and
	associated privacy policies. Location information in a PIDF-LO may		associated privacy policies. Location information in a PIDF-LO may
	be described in a geospatial manner based on a subset of GMLv3, or as		be described in a geospatial manner based on a subset of Geography
	civic location information [RFC5139]. A GML profile for expressing		Markup Language (GML) 3.1.1 [OGC-GML3.1.1], or as civic location
	geodetic shapes in a PIDF-LO is described in [GeoShape]. Uses for		information [RFC5139]. A GML profile for expressing geodetic shapes
	PIDF-LO are envisioned in the context of numerous location based		in a PIDF-LO is described in [GeoShape]. Uses for PIDF-LO are
	applications. This document makes recommendations for formats and		envisioned in the context of numerous location based applications.
	conventions to make interoperability less problematic.		This document makes recommendations for formats and conventions to
			make interoperability less problematic.
	The PIDF-LO provides a general presence format for representing		The PIDF-LO provides a general presence format for representing
	location information, and permits specification of location		location information, and permits specification of location
	information relating to a whole range of aspects of a Target. The		information relating to a whole range of aspects of a Target. The
	general presence data model is described in [RFC4479] and caters for		general presence data model is described in [RFC4479] and caters for
	a presence document to describe different aspects of the reachability		a presence document to describe different aspects of the reachability
	of a presentity. Continuing this approach, a presence document may		of a presentity. Continuing this approach, a presence document may
	contain several GEOPRIV objects that specify different locations and		contain several GEOPRIV objects that specify different locations and
	aspects of reachability relating to a presentity. This degree of		aspects of reachability relating to a presentity. This degree of
	flexibility is important, and recommendations in this document make		flexibility is important, and recommendations in this document make
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	area or volume in which a Target can be found.		area or volume in which a Target can be found.
	The term "compound location" is used to describe location information		The term "compound location" is used to describe location information
	represented by a composite of both civic and geodetic information.		represented by a composite of both civic and geodetic information.
	An example of compound location might be a geodetic polygon		An example of compound location might be a geodetic polygon
	describing the perimeter of a building and a civic element		describing the perimeter of a building and a civic element
	representing the floor in the building.		representing the floor in the building.
	The term "method" in this document refers to the mechanism used to		The term "method" in this document refers to the mechanism used to
	determine the location of a Target. This may be something employed		determine the location of a Target. This may be something employed
	by a LIS, or by the Target itself. It specifically does not refer to		by a location information server (LIS), or by the Target itself. It
	the LCP used to deliver location information either to the Target or		specifically does not refer to the location configuration protocol
			(LCP) used to deliver location information either to the Target or
	the Recipient.		the Recipient.
	The term "source" is used to refer to the LIS, node or device from		The term "source" is used to refer to the LIS, node or device from
	which a Recipient (Target or Third-Party) obtains location		which a Recipient (Target or Third-Party) obtains location
	information.		information.
	3. Using Location Information		3. Using Location Information
	The PIDF format provides for an unbounded number of <tuple>,		The PIDF format provides for an unbounded number of <tuple>,
	<device>, and <person> elements. Each of these elements contains a		<device>, and <person> elements. Each of these elements contains a
	single <status> element that may contain more than one <geopriv>		single <status> element that may contain more than one <geopriv>
	element as a child. Each <geopriv> element must contain at least the		element as a child. Each <geopriv> element must contain at least the
	following two child elements: <location-info> element and <usage-		following two child elements: <location-info> element and <usage-
	rules> element. One or more chunks of location information are		rules> element. One or more elements containing location information
	contained inside a <location-info> element.		are contained inside a <location-info> element.
	Hence, a single PIDF document may contain an arbitrary number of		Hence, a single PIDF document may contain an arbitrary number of
	location objects some or all of which may be contradictory or		location objects some or all of which may be contradictory or
	complementary. Graphically, the structure of a PIDF-LO document can		complementary. Graphically, the structure of a PIDF-LO document can
	be depicted as shown in Figure 1.		be depicted as shown in Figure 1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence>		<presence>
	<tuple> -- #1		<tuple> -- #1
	<status>		<status>
	<geopriv> -- #1		<geopriv> -- #1
	<location-info>		<location-info>
	location chunk #1		location element #1
	location chunk #2		location element #2
	...		...
	location chunk #n		location element #n
	<usage-rules>		<usage-rules>
	</geopriv>		</geopriv>
	<geopriv> -- #2		<geopriv> -- #2
	<geopriv> -- #3		<geopriv> -- #3
	...		...
	<geopriv> -- #m		<geopriv> -- #m
	</status>		</status>
	</tuple>		</tuple>
	<device>		<device>
	<geopriv> -- #1		<geopriv> -- #1
	<location-info>		<location-info>
	location chunk #1		location element(s)
	location chunk #2
	...
	location chunk #n
	<usage-rules>		<usage-rules>
	</geopriv>		</geopriv>
	<geopriv> -- #2		<geopriv> -- #2
	<geopriv> -- #3
	...		...
	<geopriv> -- #m		<geopriv> -- #m
	</device>		</device>
	<person>		<person>
	<geopriv> -- #1		<geopriv> -- #1
	<location-info>		<location-info>
	location chunk #1		location element(s)
	location chunk #2
	...
	location chunk #n
	<usage-rules>		<usage-rules>
	</geopriv>		</geopriv>
	<geopriv> -- #2		<geopriv> -- #2
	<geopriv> -- #3
	...		...
	<geopriv> -- #m		<geopriv> -- #m
	</person>		</person>
	<tuple> -- #2		<tuple> -- #2
	<device> -- #2		<device> -- #2
	<person> -- #2		<person> -- #2
	...		...
	<tuple> -- #o		<tuple> -- #o
	</presence>		</presence>
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	3.2. Civic and Geospatial Location Information		3.2. Civic and Geospatial Location Information
	Mike is visiting his Seattle office and connects his laptop into the		Mike is visiting his Seattle office and connects his laptop into the
	Ethernet port in a spare cube. In this case location information is		Ethernet port in a spare cube. In this case location information is
	geodetic location, with the altitude represented as a building floor		geodetic location, with the altitude represented as a building floor
	number. Mike's main location is the point specified by the geodetic		number. Mike's main location is the point specified by the geodetic
	coordinates. Further, Mike is on the second floor of the building		coordinates. Further, Mike is on the second floor of the building
	located at these coordinates. Applying rules #6 and #7, the		located at these coordinates. Applying rules #6 and #7, the
	resulting compound location information is shown in Figure 2.		resulting compound location information is shown in Figure 2.
	<?xml version="1.0" encoding="UTF-8"?>		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"		entity="pres:mike@seattle.example.com">
	entity="pres:mike@seattle.example.com">		<dm:device id="mikepc">
	<dm:device id="mikepc">		<gp:geopriv>
	<gp:geopriv>		<gp:location-info>
	<gp:location-info>		<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">		<gml:pos>-43.5723 153.21760</gml:pos>
	<gml:pos>-43.5723 153.21760</gml:pos>		</gml:Point>
	</gml:Point>		<cl:civicAddress>
	<cl:civicAddress>		<cl:FLR>2</cl:FLR>
	<cl:FLR>2</cl:FLR>		</cl:civicAddress>
	</cl:civicAddress>		</gp:location-info>
	</gp:location-info>		<gp:usage-rules/>
	<gp:usage-rules/>		<gp:method>Wiremap</gp:method>
	<method>Wiremap</method>		</gp:geopriv>
	</gp:geopriv>		<dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
	<dm:deviceID>		</dm:device>
	urn:uuid:f81d4fae-7dec-11d0-a765-8afd7d7d70cf		</presence>
	</dm:deviceID>
	</dm:device>
	</presence>
	Figure 2		Figure 2
	3.3. Manual/Automatic Configuration of Location Information		3.3. Manual/Automatic Configuration of Location Information
	Loraine has a predefined civic location stored in her laptop, since		Loraine has a predefined civic location stored in her laptop, since
	she normally lives in Sydney, the address is for her Sydney-based		she normally lives in Sydney, the address is for her Sydney-based
	apartment. Loraine decides to visit sunny San Francisco, and when		apartment. Loraine decides to visit sunny San Francisco, and when
	she gets there she plugs in her laptop and makes a call. Loraine's		she gets there she plugs in her laptop and makes a call. Loraine's
	laptop receives a new location from the visited network in San		laptop receives a new location from the visited network in San
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	San Francisco location first.		San Francisco location first.
	3.4. Multiple Location Objects in a Single PIDF-LO		3.4. Multiple Location Objects in a Single PIDF-LO
	Vanessa has her PC with her at the park, but due to a		Vanessa has her PC with her at the park, but due to a
	misconfiguration, her PC reports her location as being in the office.		misconfiguration, her PC reports her location as being in the office.
	The resulting PIDF-LO will have a <device> element showing the		The resulting PIDF-LO will have a <device> element showing the
	location of Vanessa's PC as the park, and a <person> element saying		location of Vanessa's PC as the park, and a <person> element saying
	that Vanessa is in her office.		that Vanessa is in her office.
	<?xml version="1.0" encoding="UTF-8"?>		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		entity="pres:ness@example.com">
	entity="pres:ness@example.com">		<dm:device id="nesspc-1">
	<dm:device id="nesspc-1">		<gp:geopriv>
	<gp:geopriv>		<gp:location-info>
	<gp:location-info>		<ca:civicAddress xml:lang="en-AU">
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">		<ca:country>AU</ca:country>
	<gml:pos>-34.410649 150.87651</gml:pos>		<ca:A1>NSW</ca:A1>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">		<ca:A3> Wollongong
	30		</ca:A3><ca:A4>North Wollongong
	</gs:radius>		</ca:A4>
	</gs:Circle>		<ca:RD>Flinders</ca:RD><ca:STS>Street</ca:STS>
	</gp:location-info>		<ca:RDBR>Campbell Street</ca:RDBR>
	<gp:usage-rules/>		<ca:LMK>
	<method>GPS</method>		Gilligan's Island
	</gp:geopriv>		</ca:LMK> <ca:LOC>Corner</ca:LOC>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<ca:NAM> Video Rental Store </ca:NAM>
	<dm:deviceID>		<ca:PC>2500</ca:PC>
	urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab		<ca:ROOM> Westerns and Classics </ca:ROOM>
	</dm:deviceID>		<ca:PLC>store</ca:PLC>
	</dm:device>		<ca:POBOX>Private Box 15</ca:POBOX>
	<dm:person id="ness">		</ca:civicAddress>
	<gp:geopriv>		</gp:location-info>
	<gp:location-info>		<gp:usage-rules/>
	<civicAddress xml:lang="en-AU">		<gp:method>GPS</gp:method>
	<country>AU</country>		</gp:geopriv>
	<A1>NSW</A1>		<dm:deviceID>mac:1234567890ab</dm:deviceID>
	<A3>Wollongong</A3>		<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
	<A4>North Wollongong</A4>		</dm:device>
	<RD>Flinders</RD><STS>Street</STS>		<dm:person id="ness">
	<RDBR>Campbell Street</RDBR>		<gp:geopriv>
	<LMK>		<gp:location-info>
	Gilligan's Island		<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	</LMK>		<gml:pos>-34.410649 150.87651</gml:pos>
	<LOC>Corner</LOC>		<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	<NAM> Main Bank </NAM>		30
	<PC>2500</PC>		</gs:radius>
	<ROOM> 398 </ROOM>		</gs:Circle>
	<PLC>store</PLC>		</gp:location-info>
	<POBOX>Private Box 15</POBOX>		<gp:usage-rules/>
	</civicAddress>		<gp:method>Manual</gp:method>
	</gp:location-info>		</gp:geopriv>
	<gp:usage-rules/>		<dm:timestamp>2007-06-24T12:28:04Z</dm:timestamp>
	<method>Manual</method>		</dm:person>
	</gp:geopriv>		</presence>
	<timestamp>2007-06-24T12:28:04Z</timestamp>
	</dm:person>
	</presence>
	Figure 3		Figure 3
	4. Geodetic Coordinate Representation		4. Geodetic Coordinate Representation
	The geodetic examples provided in RFC 4119 [RFC4119] are illustrated		The geodetic examples provided in RFC 4119 [RFC4119] are illustrated
	using the <gml:location> element, which uses the <gml:coordinates>		using the <gml:location> element, which uses the <gml:coordinates>
	element inside the <gml:Point> element and this representation has		element inside the <gml:Point> element and this representation has
	several drawbacks. Firstly, it has been deprecated in later versions		several drawbacks. Firstly, it has been deprecated in later versions
	of GML (3.1 and beyond) making it inadvisable to use for new		of GML (3.1 and beyond) making it inadvisable to use for new
	skipping to change at page 14, line 44 ¶		skipping to change at page 14, line 44 ¶
	o Ellipse (2d)		o Ellipse (2d)
	o Arc band (2d)		o Arc band (2d)
	o Sphere (3d)		o Sphere (3d)
	o Ellipsoid (3d)		o Ellipsoid (3d)
	o Prism (3d)		o Prism (3d)
	The above-listed shapes are MUST implement.		The above-listed shapes MUST be implemented.
	The GeoShape specification [GeoShape] also describes a standard set		The GeoShape specification [GeoShape] also describes a standard set
	of coordinate reference systems (CRS), unit of measure (UoM) and		of coordinate reference systems (CRS), unit of measure (UoM) and
	conventions relating to lines and distances. The use of the WGS-84		conventions relating to lines and distances. The use of the world
	coordinate reference system and the usage of EPSG-4326 (as identified		geodetic system 1984 (WGS84) [WGS84] coordinate reference system and
	by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape		the usage of European petroleum survey group (EPSG) code 4326 (as
	representations and EPSG-4979 (as identified by the URN		identified by the URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) for two
	urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume		dimensional (2d) shape representations and EPSG 4979 (as identified
	representations is mandated. Distance and heights are expressed in		by the URN urn:ogc:def:crs:EPSG::4979) for three dimensional (3d)
	meters using EPSG-9001 (as identified by the URN		volume representations is mandated. Distance and heights are
			expressed in meters using EPSG 9001 (as identified by the URN
	urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either		urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either
	degrees or radians. Measures in degrees MUST be identified by the		degrees or radians. Measures in degrees MUST be identified by the
	URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be		URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be
	identified by the URN urn:ogc:def:uom:EPSG::9101. Angles		identified by the URN urn:ogc:def:uom:EPSG::9101. Angles
	representing bearings are measured in a clockwise direction from		representing bearings are measured in a clockwise direction from
	Northing, as defined by the WGS84 CRS, not magnetic north.		Northing, as defined by the WGS84 CRS, not magnetic north.
	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 respecified or		the outermost geometry element. The CRS MUST NOT be respecified or
	changed for any sub-elements. The srsDimension attribute SHOULD be		changed for any sub-elements. The srsDimension attribute SHOULD be
	skipping to change at page 15, line 49 ¶		skipping to change at page 15, line 50 ¶
	result in significant performance impacts. To mitigate this risk		result in significant performance impacts. To mitigate this risk
	Polygon shapes SHOULD be restricted to a maximum of 15 points (16		Polygon shapes SHOULD be restricted to a maximum of 15 points (16
	including the repeated point) when the location information is		including the repeated point) when the location information is
	intended for use in real-time applications. This limit of 15 points		intended for use in real-time applications. This limit of 15 points
	is chosen to allow moderately complex shape definitions while at the		is chosen to allow moderately complex shape definitions while at the
	same time enabling interoperation with other location transporting		same time enabling interoperation with other location transporting
	protocols such as those defined in 3GPP (see [3GPP-TS-23_032]) and		protocols such as those defined in 3GPP (see [3GPP-TS-23_032]) and
	OMA where the 15 point limit is already imposed.		OMA where the 15 point limit is already imposed.
	The edges of a polygon are defined by the shortest path between two		The edges of a polygon are defined by the shortest path between two
	points in space (not a geodesic curve). Two dimensioanl points MAY		points in space (not a geodesic curve). Two dimensional points MAY
	be interpreted as having a zero valure for their altitude component.		be interpreted as having a zero valure for their altitude component.
	To avoid significant errors arising from potential geodesic		To avoid significant errors arising from potential geodesic
	interpolation, the length between adjacent vertices SHOULD be		interpolation, the length between adjacent vertices SHOULD be
	restricted to a maximum of 130km. More information relating to this		restricted to a maximum of 130km. More information relating to this
	restriction is provided in [GeoShape].		restriction is provided in [GeoShape].
	A connecting line SHALL NOT cross another connecting line of the same		A connecting line SHALL NOT cross another connecting line of the same
	Polygon.		Polygon.
	Polygons MUST be defined with the upward normal pointing up. This is		Polygons MUST be defined with the upward normal pointing up. This is
	accomplished by defining the vertices in a counter-clockwise		accomplished by defining the vertices in a counter-clockwise
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 29 ¶
	5.2. Shape Examples		5.2. Shape Examples
	This section provides some examples of where some of the more complex		This section provides some examples of where some of the more complex
	shapes are used, how they are determined, and how they are		shapes are used, how they are determined, and how they are
	represented in a PIDF-LO. Complete details on all of the GeoShape		represented in a PIDF-LO. Complete details on all of the GeoShape
	types are provided in [GeoShape].		types are provided in [GeoShape].
	5.2.1. Point		5.2.1. Point
	The point shape type is the simplest form of geodetic LI, which is		The point shape type is the simplest form of geodetic location
	natively supported by GML. The gml:Point element is used when there		information (LI), which is natively supported by GML. The gml:Point
	is no known uncertainty. A point also forms part of a number of		element is used when there is no known uncertainty. A point also
	other geometries. A point may be specified using either WGS 84		forms part of a number of other geometries. A point may be specified
	(latitude, longitude) or WGS 84 (latitude, longitude, altitude).		using either WGS 84 (latitude, longitude) or WGS 84 (latitude,
	Figure 4 shows a 2d point:		longitude, altitude). Figure 4 shows a 2d point:
	<?xml version="1.0" encoding="UTF-8"?>		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		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:civicAddr"
	xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gml="http://www.opengis.net/gml"		entity="pres:point2d@example.com">
	entity="pres:point2d@example.com">
	<dm:device id="point2d">		<dm:device id="point2d">
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>-34.407 150.883</gml:pos>		<gml:pos>-34.407 150.883</gml:pos>
	</gml:Point>		</gml:Point>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Wiremap</method>		<gp:method>Wiremap</gp:method>
	</gp:geopriv>		</gp:geopriv>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<dm:deviceID>mac:1234567890ab</dm:deviceID>
	<dm:deviceID>		<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
	urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab
	</dm:deviceID>
	</dm:device>		</dm:device>
	</presence>		</presence>
	Figure 4		Figure 4
	Figure 5 shows a 3d point:		Figure 5 shows a 3d point:
	<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	entity="pres:point3d@example.com">		entity="pres:point3d@example.com">
	<dm:device id="point3d">		<dm:device id="point3d">
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"		<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
	xmlns:gml="http://www.opengis.net/gml">		xmlns:gml="http://www.opengis.net/gml">
	<gml:pos>-34.407 150.883 24.8</gml:pos>		<gml:pos>-34.407 150.883 24.8</gml:pos>
	</gml:Point>		</gml:Point>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Wiremap</method>		<gp:method>Wiremap</gp:method>
	</gp:geopriv>		</gp:geopriv>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<dm:deviceID>mac:1234567890ab</dm:deviceID>
	<dm:deviceID>		<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
	urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab		</dm:device>
	</dm:deviceID>
	</dm:device>
	</presence>		</presence>
	Figure 5		Figure 5
	5.2.2. Polygon		5.2.2. Polygon
	The polygon shape may be used to represent a building outline or		The polygon shape may be used to represent a building outline or
	coverage area. The first and last points of the polygon have to be		coverage area. The first and last points of the polygon have to be
	the same. For example, looking at the hexagon in Figure 6 with		the same. For example, looking at the hexagon in Figure 6 with
	vertices, A, B, C, D, E, and F. The resulting polygon will be defined		vertices, A, B, C, D, E, and F. The resulting polygon will be defined
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	/ \		/ \
	/ \		/ \
	A D		A D
	\ /		\ /
	\ /		\ /
	\ /		\ /
	B--------------C		B--------------C
	Figure 6		Figure 6
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	entity="pres:hexagon@example.com">		entity="pres:hexagon@example.com">
	<tuple id="polygon-pos">		<tuple id="polygon-pos">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	<gml:pos>43.311 -73.422</gml:pos> <!--A-->		<gml:pos>43.311 -73.422</gml:pos> <!--A-->
	<gml:pos>43.111 -73.322</gml:pos> <!--B-->		<gml:pos>43.111 -73.322</gml:pos> <!--F-->
	<gml:pos>43.111 -73.222</gml:pos> <!--C-->		<gml:pos>43.111 -73.222</gml:pos> <!--E-->
	<gml:pos>43.311 -73.122</gml:pos> <!--D-->		<gml:pos>43.311 -73.122</gml:pos> <!--D-->
	<gml:pos>43.411 -73.222</gml:pos> <!--E-->		<gml:pos>43.411 -73.222</gml:pos> <!--C-->
	<gml:pos>43.411 -73.322</gml:pos> <!--F-->		<gml:pos>43.411 -73.322</gml:pos> <!--B-->
	<gml:pos>43.311 -73.422</gml:pos> <!--A-->		<gml:pos>43.311 -73.422</gml:pos> <!--A-->
	</gml:LinearRing>		</gml:LinearRing>
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Wiremap</method>		<gp:method>Wiremap</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 7		Figure 7
	In addition to the form shown in Figure 7 GML supports a posList		In addition to the form shown in Figure 7 GML supports a posList
	which provides a more compact representation for the coordinates of		which provides a more compact representation for the coordinates of
	the Polygon vertices than the discrete pos elements. The more		the Polygon vertices than the discrete pos elements. The more
	compact form is shown in Figure 8. Both forms are permitted.		compact form is shown in Figure 8. Both forms are permitted.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	entity="pres:hexagon@example.com">		entity="pres:hexagon@example.com">
	<tuple id="polygon-poslist">		<tuple id="polygon-poslist">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	<gml:posList>		<gml:posList>
	43.311 -73.422 43.111 -73.322		43.311 -73.422 43.111 -73.322
	43.111 -73.222 43.311 -73.122		43.111 -73.222 43.311 -73.122
	43.411 -73.222 43.411 -73.322		43.411 -73.222 43.411 -73.322
	43.311 -73.422		43.311 -73.422
	</gml:posList>		</gml:posList>
	</gml:LinearRing>		</gml:LinearRing>
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Wiremap</method>		<gp:method>Wiremap</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 8		Figure 8
	5.2.3. Circle		5.2.3. Circle
	The circular area is used for coordinates in two-dimensional CRSs to		The circular area is used for coordinates in two-dimensional CRSs to
	describe uncertainty about a point. The definition is based on the		describe uncertainty about a point. The definition is based on the
	one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre		one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre
	point of a circular area is specified by using a two dimensional CRS;		point of a circular area is specified by using a two dimensional CRS;
	in three dimensions, the orientation of the circle cannot be		in three dimensions, the orientation of the circle cannot be
	specified correctly using this representation. A point with		specified correctly using this representation. A point with
	uncertainty that is specified in three dimensions should use the		uncertainty that is specified in three dimensions should use the
	Sphere shape type.		Sphere shape type.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:circle@example.com">		entity="pres:circle@example.com">
	<tuple id="circle">		<tuple id="circle">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">		<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>42.5463 -73.2512</gml:pos>		<gml:pos>42.5463 -73.2512</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">		<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	850.24		850.24
	</gs:radius>		</gs:radius>
	</gs:Circle>		</gs:Circle>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>OTDOA</method>		<gp:method>OTDOA</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 9		Figure 9
	5.2.4. Ellipse		5.2.4. Ellipse
	An elliptical area describes an ellipse in two dimensional space.		An elliptical area describes an ellipse in two dimensional space.
	The ellipse is described by a center point, the length of its semi-		The ellipse is described by a center point, the length of its semi-
	major and semi-minor axes, and the orientation of the semi-major		major and semi-minor axes, and the orientation of the semi-major
	axis. Like the circular area (Circle), the ellipse MUST be specified		axis. Like the circular area (Circle), the ellipse MUST be specified
	using the two dimensional CRS.		using the two dimensional CRS.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:Ellipse@somecell.example.com">		entity="pres:Ellipse@somecell.example.com">
	<tuple id="ellipse">		<tuple id="ellipse">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">		<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>42.5463 -73.2512</gml:pos>		<gml:pos>42.5463 -73.2512</gml:pos>
	<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">		<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
	1275		1275
	</gs:semiMajorAxis>		</gs:semiMajorAxis>
	<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">		<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
	670		670
	</gs:semiMinorAxis>		</gs:semiMinorAxis>
	<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">		<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
	43.2		43.2
	</gs:orientation>		</gs:orientation>
	</gs:Ellipse>		</gs:Ellipse>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Device-Assisted_A-GPS</method>		<gp:method>Device-Assisted_A-GPS</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 10		Figure 10
	The gml:pos element indicates the position of the center, or origin,		The gml:pos element indicates the position of the center, or origin,
	of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements		of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	(3594m) `. /		(3594m) `. /
	`. ,'		`. ,'
	`. ,'		`. ,'
	r(o)`'		r(o)`'
	(4148m)		(4148m)
	Figure 11		Figure 11
	The resulting PIDF-LO is shown in Figure 12.		The resulting PIDF-LO is shown in Figure 12.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:paul@somecell.example.com">		entity="pres:paul@somecell.example.com">
	<tuple id="arcband">		<tuple id="arcband">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">		<gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>-43.5723 153.21760</gml:pos>		<gml:pos>-43.5723 153.21760</gml:pos>
	<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">		<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
	3594		3594
	</gs:innerRadius>		</gs:innerRadius>
	<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">		<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
	skipping to change at page 24, line 32 ¶		skipping to change at page 24, line 31 ¶
	</gs:outerRadius>		</gs:outerRadius>
	<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">		<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
	20		20
	</gs:startAngle>		</gs:startAngle>
	<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">		<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
	20		20
	</gs:openingAngle>		</gs:openingAngle>
	</gs:ArcBand>		</gs:ArcBand>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>TA-NMR</method>		<gp:method>TA-NMR</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 12		Figure 12
	An important note to make on the arc band is that the center point		An important note to make on the arc band is that the center point
	used in the definition of the shape is not included in resulting		used in the definition of the shape is not included in resulting
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 5 ¶
	the arc band.		the arc band.
	5.2.6. Sphere		5.2.6. Sphere
	The sphere is a volume that provides the same information as a circle		The sphere is a volume that provides the same information as a circle
	in three dimensions. The sphere has to be specified using a three		in three dimensions. The sphere has to be specified using a three
	dimensional CRS. Figure 13 shows the sphere shape, which is		dimensional CRS. Figure 13 shows the sphere shape, which is
	identical to the circle example, except for the addition of an		identical to the circle example, except for the addition of an
	altitude in the provided coordinates.		altitude in the provided coordinates.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:circle@example.com">		entity="pres:sphere@example.com">
	<tuple id="sphere">		<tuple id="sphere">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979">		<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979">
	<gml:pos>42.5463 -73.2512 26.3</gml:pos>		<gml:pos>42.5463 -73.2512 26.3</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">		<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	850.24		850.24
	</gs:radius>		</gs:radius>
	</gs:Sphere>		</gs:Sphere>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Device-Based_A-GPS</method>		<gp:method>Device-Based_A-GPS</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 13		Figure 13
	5.2.7. Ellipsoid		5.2.7. Ellipsoid
	The ellipsoid is the volume most commonly produced by GPS systems.		The ellipsoid is the volume most commonly produced by GPS systems.
	skipping to change at page 27, line 5 ¶		skipping to change at page 26, line 20 ¶
	| -c ----M---->|		| -c ----M---->|
	| |		| |
	\ /		\ /
	`._ _.'		`._ _.'
	`-...........-'		`-...........-'
	Figure 14		Figure 14
	A PIDF-LO containing an ellipsoid appears as shown in Figure 15.		A PIDF-LO containing an ellipsoid appears as shown in Figure 15.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:somone@gpsreceiver.example.com">		entity="pres:somone@gpsreceiver.example.com">
	<tuple id="ellipsoid">		<tuple id="ellipsoid">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">		<gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">
	<gml:pos>42.5463 -73.2512 26.3</gml:pos>		<gml:pos>42.5463 -73.2512 26.3</gml:pos>
	<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">		<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
	7.7156		7.7156
	</gs:semiMajorAxis>		</gs:semiMajorAxis>
	<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">		<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
	skipping to change at page 27, line 32 ¶		skipping to change at page 26, line 46 ¶
	</gs:semiMinorAxis>		</gs:semiMinorAxis>
	<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">		<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
	28.7		28.7
	</gs:verticalAxis>		</gs:verticalAxis>
	<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">		<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
	90		90
	</gs:orientation>		</gs:orientation>
	</gs:Ellipsoid>		</gs:Ellipsoid>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Hybrid_A-GPS</method>		<gp:method>Hybrid_A-GPS</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 15		Figure 15
	5.2.8. Prism		5.2.8. Prism
	A prism may be used to represent a section of a building or range of		A prism may be used to represent a section of a building or range of
	floors of building. The prism extrudes a polygon by providing a		floors of building. The prism extrudes a polygon by providing a
	height element. It consists of a base made up of coplanar points		height element. It consists of a base made up of coplanar points
	defined in 3 dimensions all at the same altitude. The prism is then		defined in 3 dimensions all at the same altitude. The prism is then
	an extrusion from this base to the value specified in the height		an extrusion from this base to the value specified in the height
	element. The height of the Prism MUST be a positive value. The		element. The height of the Prism MUST be a positive value. The
	skipping to change at page 29, line 5 ¶		skipping to change at page 28, line 5 ¶
	H--+--E |		H--+--E |
	| C--|--B		| C--|--B
	| / | /		| / | /
	|/ |/		|/ |/
	D-----A		D-----A
	Figure 16		Figure 16
	The resulting PIDF-LO is shown in Figure 17.		The resulting PIDF-LO is shown in Figure 17.
	<?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:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="pres:mike@someprism.example.com">		entity="pres:mike@someprism.example.com">
	<tuple id="prism">		<tuple id="prism">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">		<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
	<gs:base>		<gs:base>
	<gml:Polygon>		<gml:Polygon>
	<gml:exterior>		<gml:exterior>
	<gml:LinearRing>		<gml:LinearRing>
	<gml:posList>		<gml:posList>
	skipping to change at page 29, line 37 ¶		skipping to change at page 28, line 36 ¶
	</gml:LinearRing>		</gml:LinearRing>
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	</gs:base>		</gs:base>
	<gs:height uom="urn:ogc:def:uom:EPSG::9001">		<gs:height uom="urn:ogc:def:uom:EPSG::9001">
	2.4		2.4
	</gs:height>		</gs:height>
	</gs:Prism>		</gs:Prism>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>Wiremap</method>		<gp:method>Wiremap</gp:method>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	Figure 17		Figure 17
	6. Security Considerations		6. Security Considerations
	skipping to change at page 32, line 14 ¶		skipping to change at page 31, line 14 ¶
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank the GEOPRIV working group for their		The authors would like to thank the GEOPRIV working group for their
	discussions in the context of PIDF-LO, in particular Carl Reed, Ron		discussions in the context of PIDF-LO, in particular Carl Reed, Ron
	Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall		Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall
	and Robert Sparks. Furthermore, we would like to thank Jon Peterson		and Robert Sparks. Furthermore, we would like to thank Jon Peterson
	as the author of PIDF-LO and Nadine Abbott for her constructive		as the author of PIDF-LO and Nadine Abbott for her constructive
	comments in clarifying some aspects of the document.		comments in clarifying some aspects of the document.
	Thanks to Karen Navas for pointing out some emissions in the		Thanks to Karen Navas for pointing out some omissions in the
	examples.		examples.
	9. References		9. References
	9.1. Normative references		9.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.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	skipping to change at page 33, line 24 ¶		skipping to change at page 32, line 24 ¶
	[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,		[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
	July 2006.		July 2006.
	[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.
			[OGC-GML3.1.1]
			Portele, C., Cox, S., Daisy, P., Lake, R., and A.
			Whiteside, "Geography Markup Language (GML) 3.1.1",
			OGC 03-105r1, July 2003.
	[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location		[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
	Format for Presence Information Data Format Location		Format for Presence Information Data Format Location
	Object (PIDF-LO)", RFC 5139, February 2008.		Object (PIDF-LO)", RFC 5139, February 2008.
	[W3C.REC-xmlschema-2-20041028]		[W3C.REC-xmlschema-2-20041028]
	Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes		Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
	Second Edition", World Wide Web Consortium		Second Edition", World Wide Web Consortium
	Recommendation REC-xmlschema-2-20041028, October 2004,		Recommendation REC-xmlschema-2-20041028, October 2004,
	<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.		<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
	skipping to change at page 34, line 5 ¶		skipping to change at page 33, line 5 ¶
	Configuration Information", RFC 4776, November 2006.		Configuration Information", RFC 4776, November 2006.
	[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.
	[3GPP-TS-23_032]		[3GPP-TS-23_032]
	"3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;		"3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
	Technical Specification Group Code Network; Universal		Technical Specification Group Code Network; Universal
	Geographic Area Description (GAD)".		Geographic Area Description (GAD)".
			[CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03-
			105r1, November 2005.
			[WGS84] US National Imagery and Mapping Agency, "Department of
			Defense (DoD) World Geodetic System 1984 (WGS 84), Third
			Edition", NIMA TR8350.2, January 2000.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Andrew Corporation		Andrew Corporation
	Wollongong		Wollongong
	NSW Australia		NSW Australia
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@andrew.com
	Martin Thomson		Martin Thomson
	Andrew Corporation		Andrew Corporation
	Wollongong		Wollongong
	NSW Australia		NSW Australia
	Email: martin.thomson@andrew.com		Email: martin.thomson@andrew.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Email: Hannes.Tschofenig@nsn.com		Phone: +358 (50) 4871445
	URI: http://www.tschofenig.com		Email: Hannes.Tschofenig@gmx.net
			URI: http://www.tschofenig.priv.at
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		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
End of changes. 60 change blocks.
	227 lines changed or deleted		216 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/