< draft-ietf-geopriv-pdif-lo-profile-06.txt		draft-ietf-geopriv-pdif-lo-profile-07.txt >
	Geopriv J. Winterbottom		Geopriv J. Winterbottom
	Internet-Draft M. Thomson		Internet-Draft M. Thomson
	Expires: September 6, 2007 Andrew Corporation		Updates: 4119 (if approved) Andrew Corporation
	H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Siemens Networks GmbH & Co KG		Expires: October 30, 2007 Nokia Siemens Networks
	March 5, 2007		April 28, 2007
	GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations		GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
	draft-ietf-geopriv-pdif-lo-profile-06.txt		draft-ietf-geopriv-pdif-lo-profile-07.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 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 September 6, 2007.		This Internet-Draft will expire on October 30, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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 so		when information needs to be constrained in how it is represented so
	that the number of options that need to be implemented in order to		that the number of options that need to be implemented in order to
	make use of it are reduced. There is growing interest in being able		make use of it are reduced. There is growing interest in being able
	to use location information contained in a PIDF-LO for routing		to use location information contained in a PIDF-LO for routing
	applications. To allow successfully interoperability between		applications. To allow successfully 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 PIDF-LO. This		tightly constrained than is currently specified in the RFC 4119
	document makes recommendations on how to constrain, represent and		(PIDF-LO). This document makes recommendations on how to constrain,
	interpret locations in a PIDF-LO. It further recommends a subset of		represent and interpret locations in a PIDF-LO. It further
	GML that MUST be implemented by applications involved in location		recommends a subset of GML that is mandatory to implemented by
	based routing.		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 . . . . . . . . . . . . 8		3.1. Single Civic Location Information . . . . . . . . . . . . 8
	3.2. Civic and Geospatial Location Information . . . . . . . . 8		3.2. Civic and Geospatial Location Information . . . . . . . . 8
	3.3. Manual/Automatic Configuration of Location Information . . 9		3.3. Manual/Automatic Configuration of Location Information . . 9
	4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10		4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10
	5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11		5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11
	5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12		5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12
	5.2. Complex Shape Examples . . . . . . . . . . . . . . . . . . 12		5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13
	5.2.1. Polygon Representation and Usage . . . . . . . . . . . 12		5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2.2. Prism Representation and Usage . . . . . . . . . . . . 14		5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2.3. Arc Band Respresentation and Usage . . . . . . . . . . 16		5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.2.4. Ellipsoid Representation and Usage . . . . . . . . . . 18		5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Emergency Shape Representations . . . . . . . . . . . . . 20		5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 22		5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 23		5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 25
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	10.1. Normative references . . . . . . . . . . . . . . . . . . . 26		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . . 26		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . . . . 28		10.1. Normative references . . . . . . . . . . . . . . . . . . . 29
			10.2. Informative References . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
			Intellectual Property and Copyright Statements . . . . . . . . . . 31
	1. Introduction		1. Introduction
	The Presence Information Data Format Location Object (PIDF-LO) [2] is		The Presence Information Data Format Location Object (PIDF-LO) [2] is
	the IETF recommended way of encoding location information and		the recommended way of encoding location information and associated
	associated privacy policies. Location information in a PIDF-LO may		privacy policies. Location information in a PIDF-LO may be described
	be described in a geospatial manner based on a subset of GMLv3, or as		in a geospatial manner based on a subset of GMLv3, or as civic
	civic location information [4]. A GML profile for expressing		location information [5]. A GML profile for expressing geodetic
	geodetic shapes in a PIDF-LO is described in [6]. Uses for PIDF-LO		shapes in a PIDF-LO is described in [3]. Uses for PIDF-LO are
	are envisioned in the context of numerous location based		envisioned in the context of numerous location based applications.
	applications. This document makes recommendations for formats and		This document makes recommendations for formats and conventions to
	conventions to make interoperability less problematic.		make interoperability less problematic.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	The definition for "Target" is taken from [5].		The definition for "Target" is taken from [6].
	In this document a "discrete location" is defined as a place, point,		In this document a "discrete location" is defined as a place, point,
	area or volume in which a Target can be found. It must be described		area or volume in which a Target can be found. It must be described
	with sufficient precision to address the requirements of an intended		with sufficient precision to address the requirements of an intended
	application.		application.
	The term "location complex" 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 a location complex 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.
	3. Using Location Information		3. Using Location Information
	The PIDF format provides for an unbounded number of tuples. The		The PIDF format provides for an unbounded number of <tuple> elements.
	geopriv element resides inside the status component of a tuple, hence		Each <tuple> element contains a single <status> element that may
	a single PIDF document may contain an arbitrary number of location		contain more than one <geopriv> element as a child element. Each
	objects some or all of which may be contradictory or complementary.		<geopriv> element must contain at least the following two child
	The actual location information is contained inside a <location-info>		elements: <location-info> element and <usage-rules> element. One or
	element, and there may be one or more actual locations described		more chunks of location information are contained inside a <location-
	inside the <location-info> element.		info> element.
	Graphically, the structure of the PIDF-LO can be depicted as follows:		Hence, a single PIDF document may contain an arbitrary number of
			location objects some or all of which may be contradictory or
			complementary. Graphically, the structure of a PIDF-LO document can
			be depicted as shown in Figure 1.
	PIDF document		<?xml version="1.0" encoding="UTF-8"?>
	tuple 1		<presence>
	status		<tuple> -- #1
	geopriv		<status>
	location-info		<geopriv> -- #1
	civicAddress		<location-info>
	geodetic		location chunk #1
	location...		location chunk #2
	usage-rules		...
	geopriv 2		location chunk #n
	geopriv 3		<usage-rules>
	.		</geopriv>
	.		<geopriv> -- #2
	.		<geopriv> -- #3
			...
			<geopriv> -- #m
			</status>
			</tuple>
			<tuple> -- #2
			<tuple> -- #3
			...
			<tuple> -- #o
			</presence>
	tuple 2		Figure 1: Structure of a PIDF-LO Document
	tuple 3
	All of these potential sources and storage places for location lead		All of these potential sources and storage places for location lead
	to confusion for the generators, conveyors and users of location		to confusion for the generators, conveyors and consumers of location
	information. Practical experience within the United States National		information. Practical experience within the United States National
	Emergency Number Association (NENA) in trying to solve these		Emergency Number Association (NENA) in trying to solve these
	ambiguities led to a set of conventions being adopted. These rules		ambiguities led to a set of conventions being adopted. These rules
	do not have any particular order, but should be followed by creators		do not have any particular order, but should be followed by creators
	and users of location information contained in a PIDF-LO to ensure		and consumers of location information contained in a PIDF-LO to
	that a consistent interpretation of the data can be achieved.		ensure that a consistent interpretation of the data can be achieved.
	Rule #1: A geopriv element MUST describe a discrete location.		Rule #1: A <geopriv> element MUST describe a discrete location.
	Rule #2: Where a discrete location can be uniquely described in more		Rule #2: Where a discrete location can be uniquely described in more
	than one way, each location description SHOULD reside in a		than one way, each location description SHOULD reside in a
	separate tuple.		separate <tuple> element.
	Rule #3: Providing more than one location in a single presence		Rule #3: Providing more than one location chunk in a single presence
	document (PIDF) MUST only be done if all objects describe the same		document (PIDF) MUST only be done if all objects refer to the same
	location. This may occur if a Target's location is determined		place.
	using a series of different techniques.
	Rule #4: Providing more than one location in a single <location-		This may occur if a Target's location is determined using a
	info> element SHOULD be avoided where possible.		series of different techniques.
	Rule #5: When providing more than one location in a single		Rule #4: Providing more than one location chunk in a single
			<location-info> element SHOULD be avoided where possible. Rule #5
			and Rule #6 provide further refinement.
			Rule #5: When providing more than one location chunk in a single
	<location-info> element the locations MUST be provided by a common		<location-info> element the locations MUST be provided by a common
	source at the same time and by the same method.		source at the same time and by the same location determination
			method.
	Rule #6: Providing more than one location in a single <location-		Rule #6: Providing more than one location chunk in a single
	info> element SHOULD only be done if they form a complex to		<location-info> element SHOULD only be used for representing
	describe the same location. For example, a geodetic location		compound location referring to the same place.
	describing a point, and a civic location indicating the floor in a
	building.
	Rule #7: Where a location complex is provided in a single <location-		For example, a geodetic location describing a point, and a
			civic location indicating the floor in a building.
			Rule #7: Where compound location is provided in a single <location-
	info> element, the coarse location information MUST be provided		info> element, the coarse location information MUST be provided
	first. For example, a geodetic location describing an area, and a		first.
	civic location indicating the floor should be represented with the
	area first followed by the civic location.
	Rule #8: Where a PIDF document contains more than one tuple		For example, a geodetic location describing an area, and a
	containing a status element with a geopriv location element , the		civic location indicating the floor should be represented with
	priority of tuples SHOULD be based on tuple position within the		the area first followed by the civic location.
	PIDF document. That is to say, the tuple with the highest
	priority location occurs earliest in the PIDF document.		Rule #8: Where a PIDF document contains more than one <tuple>
			element containing a <status> element with a <geopriv> element,
			the priority of tuples SHOULD be based on position of the <tuple>
			element within the PIDF document. That is to say, the tuple with
			the highest priority location occurs earliest in the PIDF
			document.
	Rule #9: Where multiple PIDF documents can be sent or received		Rule #9: Where multiple PIDF documents can be sent or received
	together, say in a multi-part MIME body, and current location		together, say in a multi-part MIME body, and current location
	information is required by the recipient, then document selection		information is required by the recipient, then document selection
	SHOULD be based on document order, with the first document be		SHOULD be based on document order, with the first document be
	considered first.		considered first.
	The following examples illustrate the application of these rules.		The following examples illustrate the application of these rules.
	3.1. Single Civic Location Information		3.1. Single Civic Location Information
	Jane is at a coffee shop on the ground floor of a large shopping		Jane is at a coffee shop on the ground floor of a large shopping
	mall. Jane turns on her laptop and connects to the coffee-shop's		mall. Jane turns on her laptop and connects to the coffee-shop's
	WiFi hotspot, Jane obtains a complete civic address for her current		WiFi hotspot, Jane obtains a complete civic address for her current
	location, for example using the DHCP civic mechanism defined in [3].		location, for example using the DHCP civic mechanism defined in [4].
	A Location Object is constructed consisting of a single PIDF		A Location Object is constructed consisting of a single PIDF
	document, with a single geopriv tuple, and a single location residing		document, with a single <tuple> element, a single <status> element, a
	in the <location-info> element. This document is unambiguous, and		single <geopriv> element, and a single location chunk residing in the
	should be interpreted consistently by receiving nodes if sent over		<location-info> element. This document is unambiguous, and should be
	the network.		interpreted consistently by receiving nodes if sent over the network.
	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 the location is a		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 are applied,		located at these coordinates. Applying rules #6 and #7 are applied,
	the PIDF-LO document creates a complex as shown below.		the resulting compound location information is shown below.
	<?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: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:mike@seattle.example.com">		entity="pres:mike@seattle.example.com">
	<tuple id="sg89ab">		<tuple id="sg89ab">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 41 ¶
	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
	Francisco. As this system cannot be sure that the pre-existing, and		Francisco. As this system cannot be sure that the pre-existing, and
	new location, describe the same place, Loraine's computer generates a		new location, describe the same place, Loraine's computer generates a
	new PIDF-LO and will use this to represent Loraine's location. If		new PIDF-LO and will use this to represent Loraine's location. If
	Loraine's computer were to add the new location to her existing PIDF		Loraine's computer were to add the new location to her existing PIDF
	location document (breaking rule #3), then the correct information		location document (breaking rule #3), then the correct information
	may still be interpreted by location recipient providing Loraine's		may still be interpreted by the Location Recipient providing
	system applies rule #9. In this case the resulting order of location		Loraine's system applies rule #9. In this case the resulting order
	information in the PIDF document should be San Francisco first,		of location information in the PIDF document should be San Francisco
	followed by Sydney. Since the information is provided by different		first, followed by Sydney. Since the information is provided by
	sources, rule #8 should also be applied and the information placed in		different sources, rule #8 should also be applied and the information
	different tuples with the tuple containing the San Francisco location		placed in different tuples with the tuple containing the San
	first.		Francisco location first.
	4. Geodetic Coordinate Representation		4. Geodetic Coordinate Representation
	The geodetic examples provided in RFC 4119 [2] are illustrated using		The geodetic examples provided in RFC 4119 [2] are illustrated using
	the gml:location element which uses the gml:coordinates elements		the <gml:location> element, which uses the <gml:coordinates> element
	(inside the gml:Point element) and this representation has several		inside the <gml:Point> element and this representation has several
	drawbacks. Firstly, it has been deprecated in later versions of GML		drawbacks. Firstly, it has been deprecated in later versions of GML
	(3.1 and beyond) making it inadvisable to use for new applications.		(3.1 and beyond) making it inadvisable to use for new applications.
	Secondly, the format of the coordinates type is opaque and so can be		Secondly, the format of the coordinates type is opaque and so can be
	difficult to parse and interpret to ensure consistent results, as the		difficult to parse and interpret to ensure consistent results, as the
	same geodetic location can be expressed in a variety of ways. The		same geodetic location can be expressed in a variety of ways. The
	PIDF-LO Geodetic Shapes specification [6] provides a specific GML		PIDF-LO Geodetic Shapes specification [3] provides a specific GML
	profile for expressing commonly used shapes using simple GML		profile for expressing commonly used shapes using simple GML
	representations. The shapes defined in [6] are the recommended		representations. The shapes defined in [3] are the recommended
	shapes to ensure interoperability between location based		shapes to ensure interoperability.
	applications.
	5. Geodetic Shape Representation		5. Geodetic Shape Representation
	The cellular mobile world today makes extensive use of geodetic based		The cellular mobile world today makes extensive use of geodetic based
	location information for emergency and other location-based		location information for emergency and other location-based
	applications. Generally these locations are expressed as a point		applications. Generally these locations are expressed as a point
	(either in two or three dimensions) and an area or volume of		(either in two or three dimensions) and an area or volume of
	uncertainty around the point. In theory, the area or volume		uncertainty around the point. In theory, the area or volume
	represents a coverage in which the user has a relatively high		represents a coverage in which the user has a relatively high
	probability of being found, and the point is a convenient means of		probability of being found, and the point is a convenient means of
	defining the centroid for the area or volume. In practice, most		defining the centroid for the area or volume. In practice, most
	systems use the point as an absolute value and ignore the		systems use the point as an absolute value and ignore the
	uncertainty. It is difficult to determine if systems have been		uncertainty. It is difficult to determine if systems have been
	implemented in this manner for simplicity, and even more difficult to		implemented in this manner for simplicity, and even more difficult to
	predict if uncertainty will play a more important role in the future.		predict if uncertainty will play a more important role in the future.
	An important decision is whether an uncertainty area should be		An important decision is whether an uncertainty area should be
	specified.		specified.
	The PIDF-LO Geodetic Shapes specification [6] defines eight shape		The PIDF-LO Geodetic Shapes specification [3] defines eight shape
	types most of which are easily translated into shapes definitions		types most of which are easily translated into shapes definitions
	used in other applications and protocols, such as Open Mobile		used in other applications and protocols, such as Open Mobile
	Alliance (OMA) Mobile Location Protocol (MLP). For completeness the		Alliance (OMA) Mobile Location Protocol (MLP). For completeness the
	shapes defined in [6] are listed below:		shapes defined in [3] are listed below:
	o Point (2d or 3d)		o Point (2d and 3d)
	o Polygon (2d)		o Polygon (2d)
	o Circle (2d)		o Circle (2d)
	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 GeoShape specification [6] also describes a standard set of		All above-listed shapes are mandatory to implement.
			The GeoShape specification [3] also describes a standard set of
	coordinate reference systems (CRS), unit of measure (UoM) and		coordinate reference systems (CRS), unit of measure (UoM) and
	conventions relating to lines and distances. GeoShape mandates the		conventions relating to lines and distances. The use of the WGS-84
	use the WGS-84 Coordinate reference system and restricts usage to		coordinate reference system and the usage of EPSG-4326 (as identified
	EPSG-4326 for two dimensional (2d) shape representations and EPSG-		by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape
	4979 for three dimensional (3d) volume representations. Distance and		representations and EPSG-4979 (as identified by the URN
	heights are expressed in meters using EPSG-9001.		urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) 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
			degrees or radians. Measures in degrees MUST be identified by the
			URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be
			identified by the URN urn:ogc:def:uom:EPSG::9101
			Implementations MUST specify the CRS using the srsName attribute on
			the outermost geometry element. The CRS MUST NOT be respecified or
			changed for any sub-elements. The srsDimension attribute SHOULD be
			omitted, since the number of dimensions in these CRSs is known. A
			CRS MUST be specified using the above URN notation only,
			implementations do not need to support user-defined CRSs.
	It is RECOMMENDED that where uncertainty is included, a confidence of		It is RECOMMENDED that where uncertainty is included, a confidence of
	68% (or one standard deviation) is used. Specifying a convention for		68% (or one standard deviation) is used. Specifying a convention for
	confidence enables better use of uncertainty values.		confidence enables better use of uncertainty values.
	5.1. Polygon Restrictions		5.1. Polygon Restrictions
	The Polygon shape type defined in [6] intentionally does not place		The Polygon shape type defined in [3] intentionally does not place
	any constraints on the number of vertices that may be included to		any constraints on the number of vertices that may be included to
	define the bounds of the Polygon. This allows arbitrarily complex		define the bounds of a polygon. This allows arbitrarily complex
	shapes to be defined and conveyed in a PIDF-LO. However where		shapes to be defined and conveyed in a PIDF-LO. However, where
	location information is to be used in real-time processing		location information is to be used in real-time processing
	applications, such as location dependent routing, having arbitrarily		applications, such as location dependent routing, having arbitrarily
	complex shapes consisting of tens or even hundreds of points could		complex shapes consisting of tens or even hundreds of points could
	result in significant performance impacts. To mitigate this risk it		result in significant performance impacts. To mitigate this risk it
	is recommended that Polygons be restricted to a maximum of 15		is recommended that Polygon shapes be restricted to a maximum of 15
	discrete points (16 including the repeated point) when the location		points (16 including the repeated point) when the location
	information is intended for use in real-time applications. This		information is intended for use in real-time applications. This
	limit of 15 points is chosen to allow moderately complex shape		limit of 15 points is chosen to allow moderately complex shape
	definitions while at the same time enabling interoperation with other		definitions while at the same time enabling interoperation with other
	location transporting protocols such as those defined in 3GPP ([7])		location transporting protocols such as those defined in 3GPP (see
	and OMA where the 15 point limit is already imposed.		[8]) and OMA where the 15 point limit is already imposed.
	Polygons are defined with the minimum distance between two adjacent		Polygons are defined with the minimum distance between two adjacent
	vertices (geodesic). A connecting line SHALL NOT cross another		vertices (geodesic). A connecting line SHALL NOT cross another
	connecting line of the same Polygon. Polygons SHOULD be defined with		connecting line of the same Polygon. Polygons SHOULD be defined with
	the upward normal pointing up, this is accomplished by defining the		the upward normal pointing up, this is accomplished by defining the
	vertices in counter-clockwise direction.		vertices in counter-clockwise direction.
	Points specified in a polygon must be coplanar, and it is recommended		Points specified in a polygon MUST be coplanar, and it is RECOMMENDED
	that where points are specified in 3 dimensions that all points		that where points are specified in 3 dimensions that all points
	maintain the same altitude.		maintain the same altitude.
	5.2. Complex 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 [6].		types are provided in [3].
	5.2.1. Polygon Representation and Usage		5.2.1. Point
			The point shape type is the simplest form of geodetic LI, which is
			natively supported by GML. The gml:Point element is used when there
			is no known uncertainty. A point also forms part of a number of
			other geometries. A point may be specified using either WGS 84
			(latitude, longitude) or WGS 84 (latitude, longitude, altitude). The
			next example shows a 2d point:
			<?xml version="1.0" encoding="UTF-8"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
			xmlns:gml="http://www.opengis.net/gml"
			entity="pres:point2d@example.com">
			<tuple id="sg89abcd">
			<status>
			<gp:geopriv>
			<gp:location-info>
			<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
			xmlns:gml="http://www.opengis.net/gml">
			<gml:pos>-34.407 150.883</gml:pos>
			</gml:Point>
			</gp:location-info>
			<gp:usage-rules/>
			</gp:geopriv>
			</status>
			<timestamp>2007-06-22T20:57:29Z</timestamp>
			</tuple>
			</presence>
			The next example shows a 3d point:
			<?xml version="1.0" encoding="UTF-8"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
			xmlns:gml="http://www.opengis.net/gml"
			entity="pres:point3d@example.com">
			<tuple id="sg89ab5">
			<status>
			<gp:geopriv>
			<gp:location-info>
			<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
			xmlns:gml="http://www.opengis.net/gml">
			<gml:pos>-34.407 150.883 24.8</gml:pos>
			</gml:Point>
			</gp:location-info>
			<gp:usage-rules/>
			</gp:geopriv>
			</status>
			<timestamp>2007-06-22T20:57:29Z</timestamp>
			</tuple>
			</presence>
			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 must be the		coverage area. The first and last points of the polygon have to be
	same to form a closed shape. For example looking at the octagon		the same. For example, looking at the octagon below with vertices,
	below with vertices, A,H,G,F,E,D,C,B,A. The resulting polygon will be		A, H, G, F, E, D, C, B, A. The resulting polygon will be defined with
	defined with 9 points, with the first and last points both having the		9 points, with the first and last points both having the coordinates
	coordinates of point A.		of point A.
	B-------------C		B-------------C
	/ \		/ \
	/ \		/ \
	/ \		/ \
	A D		A D
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	skipping to change at page 14, line 39 ¶		skipping to change at page 15, line 39 ¶
	</gml:exterior>		</gml:exterior>
	</gml:Polygon>		</gml:Polygon>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2007-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	5.2.2. Prism Representation and Usage		5.2.3. Circle
	A prsim may be used to represent a section of a building or range of		The circular area is used for coordinates in two-dimensional CRSs to
	floors of building. The prism extrudes a polygon by providing a		describe uncertainty about a point. The definition is based on the
	height element. It consists of a base made up of coplanar 3 points		one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre
	defined in 3 dimensions all at the same altitude. The prism is then		point of a circular area is specified by using a two dimensional CRS;
	an extrusion from this base to the value specified in the height		in three dimensions, the orientation of the circle cannot be
	element. If the height is negative, then the prism is extruded from		specified correctly using this representation. A point with
	the top down, while a positive height extrudes from the bottom up.		uncertainty that is specified in three dimensions should use the
	The first and last points of the polygon must be the same to form a		Sphere shape type.
	closed shape.
	For example looking at the cube below. If the prism is extruded from		<?xml version="1.0" encoding="UTF-8"?>
	the bottom up, then the polygon forming the base of the prism is		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	defined with the points A, B, C, D, A. The height of the prism is the		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	distance between point A and point E in meters. The resulting		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	PIDF-LO is provided below.		xmlns:gs="http://www.opengis.net/pidflo/1.0"
			xmlns:gml="http://www.opengis.net/gml"
			entity="pres:circle@example.com">
			<tuple id="sg89ab1">
			<status>
			<gp:geopriv>
			<gp:location-info>
			<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
			<gml:pos>
			42.5463 -73.2512
			</gml:pos>
			<gml:radius uom="urn:ogc:def:uom:EPSG::9001">
			850.24
			</gml:radius>
			</gs:Circle>
			</gp:location-info>
			</gp:geopriv>
			</status>
			</tuple>
			</presence>
	G-----F		5.2.4. Ellipse
	/| /|
	/ | / |		An elliptical area describes an ellipse in two dimensional space.
	H--+--E |		The ellipse is described by a center point, the length of its semi-
	| C--|--B		major and semi-minor axes, and the orientation of the semi-major
	| / | /		axis. Like the circular area (Circle), the ellipse MUST be specified
	|/ |/		using a two dimensional CRS.
	D-----A
	<?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:civicAddr"		xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	entity="pres:mike@someprism.example.com">		entity="pres:Ellipse@somecell.example.com">
	<tuple id="sg89ab">		<tuple id="sg89ab7">
	<status>		<status>
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">		<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
	<gs:base>		<gml:pos>
	<gml:Polygon>		42.5463 -73.2512
	<gml:exterior>		</gml:pos>
	<gml:LinearRing>		<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
	<gml:posList>		1275
	42.556844 -73.248157 36.6 <!--A-->		</gs:semiMajorAxis>
	42.656844 -73.248157 36.6 <!--B-->		<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
	42.656844 -73.348157 36.6 <!--C-->		670
	42.556844 -73.348157 36.6 <!--D-->		</gs:semiMinorAxis>
	42.556844 -73.248157 36.6 <!--A-->		<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
	</gml:posList>		43.2
	</gml:LinearRing>		</gs:orientation>
	</gml:exterior>		</gs:Ellipse>
	</gml:Polygon>
	</gs:base>
	<gs:height uom="urn:ogc:def:uom:EPSG::9001">
	2.4
	</gs:height>
	</gs:Prism>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2007-06-22T20:57:29Z</timestamp>		<timestamp>2003-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	5.2.3. Arc Band Respresentation and Usage		The gml:pos element indicates the position of the center, or origin,
			of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements
			are the length of the semi-major and semi-minor axes respectively.
			The gs:orientation element is the angle by which the semi-major axis
			is rotated from the first axis of the CRS towards the second axis.
			For WGS 84, the orientation indicates rotation from Northing to
			Easting, which, if specified in degrees, is roughly equivalent to a
			compass bearing (if magnetic north were the same as the WGS north
			pole). Note: An ellipse with equal major and minor axis lengths is a
			circle.
			5.2.5. Arc Band
	The arc band shape type is commonly generated in wireless systems		The arc band shape type is commonly generated in wireless systems
	where timing advance or code offsets sequences are used to compensate		where timing advance or code offsets sequences are used to compensate
	for distances between handsets and the access point. The arc band is		for distances between handsets and the access point. The arc band is
	represented as two radii emanating from a central point, and two		represented as two radii emanating from a central point, and two
	angles which represent the starting angle and the opening angle of		angles which represent the starting angle and the opening angle of
	the arc. In a cellular environment the central point is nominally		the arc. In a cellular environment the central point is nominally
	the location of the cell tower, the two radii are determined by the		the location of the cell tower, the two radii are determined by the
	extent of the timing advance, and the two angles are generally		extent of the timing advance, and the two angles are generally
	provisioned information.		provisioned information.
	skipping to change at page 18, line 46 ¶		skipping to change at page 19, line 46 ¶
	</status>		</status>
	<timestamp>2003-06-22T20:57:29Z</timestamp>		<timestamp>2003-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	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
	enclosed area, and that Target may be anywhere in the defined area of		enclosed area, and that Target may be anywhere in the defined area of
	the arc band.		the arc band.
	5.2.4. Ellipsoid Representation and Usage		5.2.6. Sphere
			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
			dimensional CRS. The following example shows a sphere shape, which
			is identical to the circle example, except for the addition of an
			altitude in the provided coordinates.
			<?xml version="1.0" encoding="UTF-8"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
			xmlns:gml="http://www.opengis.net/gml"
			entity="pres:circle@example.com">
			<tuple id="sg89ab1">
			<status>
			<gp:geopriv>
			<gp:location-info>
			<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979">
			<gml:pos>
			42.5463 -73.2512 26.3
			</gml:pos>
			<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
			850.24
			</gs:radius>
			</gs:Sphere>
			</gp:location-info>
			</gp:geopriv>
			</status>
			</tuple>
			</presence>
			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.
	It is used extensively in navigation systems and wireless location		It is used extensively in navigation systems and wireless location
	networks. The ellipsoid is constructed around a central point		networks. The ellipsoid is constructed around a central point
	specified in three dimensions, and three axies perpendicular to one		specified in three dimensions, and three axies perpendicular to one
	another are extended outwards from this point. These axies are		another are extended outwards from this point. These axies are
	defined as the semi-major (M) axis, the semi-minor (m) axis, and the		defined as the semi-major (M) axis, the semi-minor (m) axis, and the
	vertical (v) axis respectively. An angle is used to express the		vertical (v) axis respectively. An angle is used to express the
	orientation of the ellipsoid. The orientation angle is measured in		orientation of the ellipsoid. The orientation angle is measured in
	degrees from north, and represents the direction of the semi-major		degrees from north, and represents the direction of the semi-major
	skipping to change at page 20, line 41 ¶		skipping to change at page 22, line 41 ¶
	</gs:orientation>		</gs:orientation>
	</gs:Ellipsoid>		</gs:Ellipsoid>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	</gp:geopriv>		</gp:geopriv>
	</status>		</status>
	<timestamp>2003-06-22T20:57:29Z</timestamp>		<timestamp>2003-06-22T20:57:29Z</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	5.3. Emergency Shape Representations		5.2.8. Prism
	In some parts of the world cellular networks constraints are placed		A prism may be used to represent a section of a building or range of
	on the shape types that can be used to represent the location of an		floors of building. The prism extrudes a polygon by providing a
	emergency caller. These restrictions, while to some extend are		height element. It consists of a base made up of coplanar 3 points
	artificial, may pose significant interoperability problems in		defined in 3 dimensions all at the same altitude. The prism is then
	emergency networks were they to be unilaterally lifted. The largest		an extrusion from this base to the value specified in the height
	impact likely being on Public Safety Answer Point (PSAP) where		element. If the height is negative, then the prism is extruded from
	multiple communication networks report emergency data. Wholesale		the top down, while a positive height extrudes from the bottom up.
	swap-out or upgrading of this equipment is deemed to be complex and		The first and last points of the polygon have to be the same.
	costly and has resulted in a number of countries, most notably the
	United States, to adopt migratory standards towards emergency IP
	telephony support. Where these migratory standards are implemented
	restrictions on acceptable geodetic shape types to represent the
	location of an emergency caller may exist. Conversion from one shape
	type to another should be avoided to eliminate the introduction of
	errors in reported location.
	In North America the migratory VoIP emergency services standard (i2)		For example, looking at the cube below. If the prism is extruded
	[8] reuses the NENA E2 interface [9] which restriction geodetic shape		from the bottom up, then the polygon forming the base of the prism is
	representation to a point, a point with an uncertain circle, a point		defined with the points A, B, C, D, A. The height of the prism is the
	with an altitude and an uncertainty circle. The NENA recommended		distance between point A and point E in meters. The resulting
	shapes can be represented in a PIDF-LO using the GeoShape Point,		PIDF-LO is provided below.
	GeoShape Circle, and GeoShape Sphere definitions respectively.
			G-----F
			/| /|
			/ | / |
			H--+--E |
			| C--|--B
			| / | /
			|/ |/
			D-----A
			<?xml version="1.0" encoding="UTF-8"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
			xmlns:gml="http://www.opengis.net/gml"
			entity="pres:mike@someprism.example.com">
			<tuple id="sg89ab">
			<status>
			<gp:geopriv>
			<gp:location-info>
			<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
			<gs:base>
			<gml:Polygon>
			<gml:exterior>
			<gml:LinearRing>
			<gml:posList>
			42.556844 -73.248157 36.6 <!--A-->
			42.656844 -73.248157 36.6 <!--B-->
			42.656844 -73.348157 36.6 <!--C-->
			42.556844 -73.348157 36.6 <!--D-->
			42.556844 -73.248157 36.6 <!--A-->
			</gml:posList>
			</gml:LinearRing>
			</gml:exterior>
			</gml:Polygon>
			</gs:base>
			<gs:height uom="urn:ogc:def:uom:EPSG::9001">
			2.4
			</gs:height>
			</gs:Prism>
			</gp:location-info>
			<gp:usage-rules/>
			</gp:geopriv>
			</status>
			<timestamp>2007-06-22T20:57:29Z</timestamp>
			</tuple>
			</presence>
	6. Recommendations		6. Recommendations
	As a summary, this document gives a few recommendations on the usage		As a summary, this document gives a few recommendations on the usage
	of location information in PIDF-LO. Nine rules specified in		of location information in PIDF-LO. Nine rules specified in
	Section 3 give guidelines on avoiding ambiguity in PIDF-LO		Section 3 give guidelines on avoiding ambiguity in PIDF-LO
	interpretations when multiple locations may be provided to a Target		interpretations when multiple locations may be provided to a Target
	or location recipient.		or location recipient.
	It is recommended that only the shape types and shape representations		It is recommended that only the shape types and shape representations
	described in [6] be used to express geodetic locations for exchange		described in [3] be used to express geodetic locations for exchange
	between general applications. By standardizing geodetic data		between general applications. By standardizing geodetic data
	representation interoperability issues are mitigated.		representation interoperability issues are mitigated.
	It is recommended that GML Polygons be restricted to a maximum of 16		It is recommended that GML Polygons be restricted to a maximum of 16
	points when used in location-dependent routing and other real-time		points when used in location-dependent routing and other real-time
	applications to mitigate possible performance issues. This allows		applications to mitigate possible performance issues. This allows
	for interoperability with other location protocols where this		for interoperability with other location protocols where this
	restriction applies.		restriction applies.
	Geodetic location may require restricted shape definitions in regions		Geodetic location may require restricted shape definitions in regions
	skipping to change at page 26, line 9 ¶		skipping to change at page 29, line 9 ¶
	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 and Henning Schulzrinne. Furthermore, we would like		Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
	to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for		to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
	her constructive comments in clarifying some aspects of the document.		her constructive comments in clarifying some aspects of the document.
	10. References		10. References
	10.1. Normative references		10.1. Normative references
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	[2] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.
	[3] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
	and DHCPv6) Option for Civic Addresses Configuration
	Information", RFC 4676, October 2006.
	[4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
	for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
	progress), February 2007.
	[5] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.		[2] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
	Polk, "Geopriv Requirements", RFC 3693, February 2004.		RFC 4119, December 2005.
	[6] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application		[3] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application
	Schema for use by the Internet Engineering Task Force (IETF)",		Schema for use by the Internet Engineering Task Force (IETF)",
	Candidate OpenGIS Implementation Specification 06-142, Version:		Candidate OpenGIS Implementation Specification 06-142, Version:
	0.0.9, December 2006.		0.0.9, December 2006.
	10.2. Informative References		10.2. Informative References
	[7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;		[4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
	Technical Specification Group Code Network; Universal		and DHCPv6) Option for Civic Addresses Configuration
	Geographic Area Description (GAD)".		Information", RFC 4776, November 2006.
	[8] "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP		[5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
	Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec		for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
	2005".		progress), February 2007.
	[9] "NENA Standard for the Implementation of the Wireless Emergency		[6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
	Service Protocol E2 Interface, NENA 05-001, Dec 2003".		Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host		[7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based Location		Configuration Protocol Option for Coordinate-based Location
	Configuration Information", RFC 3825, July 2004.		Configuration Information", RFC 3825, July 2004.
			[8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
			Technical Specification Group Code Network; Universal Geographic
			Area Description (GAD)".
	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
	Siemens Networks GmbH & Co KG		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
			URI: http://www.tschofenig.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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. 69 change blocks.
	236 lines changed or deleted		418 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/