Diff: draft-forte-lost-extensions-07.txt - draft-forte-lost-extensions-08.txt

	< draft-forte-lost-extensions-07.txt	draft-forte-lost-extensions-08.txt >

	Network Working Group A. Forte	Network Working Group A. Forte
	Internet-Draft AT&T	Internet-Draft AT&T
	Intended status: Experimental H. Schulzrinne	Intended status: Experimental H. Schulzrinne

	Expires: January 26, 2012 Columbia University	Expires: March 10, 2012 Columbia University
	July 25, 2011	September 7, 2011

	Location-to-Service Translation (LoST) Protocol Extensions	Location-to-Service Translation (LoST) Protocol Extensions

	draft-forte-lost-extensions-07.txt	draft-forte-lost-extensions-08.txt

	Abstract	Abstract

	An important class of location-based services answer the question	An important class of location-based services answer the question
	"What instances of this service are closest to me?" Examples include	"What instances of this service are closest to me?" Examples include
	finding restaurants, gas stations, stores, automated teller machines,	finding restaurants, gas stations, stores, automated teller machines,
	wireless access points (hot spots) or parking spaces. Currently, the	wireless access points (hot spots) or parking spaces. Currently, the
	Location-to-Service Translation (LoST) protocol only supports mapping	Location-to-Service Translation (LoST) protocol only supports mapping
	locations to a single service based on service regions. This	locations to a single service based on service regions. This
	document describes an extension that allows queries of the type "N	document describes an extension that allows queries of the type "N

	skipping to change at page 1, line 38 ¶	skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.	Drafts is at http://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	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."


	This Internet-Draft will expire on January 26, 2012.	This Internet-Draft will expire on March 10, 2012.

	Copyright Notice	Copyright Notice

	Copyright (c) 2011 IETF Trust and the persons identified as the	Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents

	skipping to change at page 2, line 25 ¶	skipping to change at page 2, line 25 ¶
	distance X" and "served by" . . . . . . . . . . . . . . . . . 5	distance X" and "served by" . . . . . . . . . . . . . . . . . 5
	5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5	5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5	5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5
	5.2. Queries Based on Service Regions . . . . . . . . . . . . . 8	5.2. Queries Based on Service Regions . . . . . . . . . . . . . 8
	5.3. Difference Between "within distance X" and "served by"	5.3. Difference Between "within distance X" and "served by"
	Queries . . . . . . . . . . . . . . . . . . . . . . . . . 10	Queries . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Limiting the Number of Returned Service URIs . . . . . . . 11	5.4. Limiting the Number of Returned Service URIs . . . . . . . 11
	5.5. The <serviceLocation> Element in Responses . . . . . . . . 13	5.5. The <serviceLocation> Element in Responses . . . . . . . . 13
	6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 16	6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 16
	7. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 17	7. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 17

	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9.1. LoST Extensions Relax NG Schema Registration . . . . . . . 19	9.1. LoST Extensions Relax NG Schema Registration . . . . . . . 19

	9.2. LoST Extensions Namespace Registration . . . . . . . . . . 19	9.2. LoST Extensions Namespace Registration . . . . . . . . . . 20
	10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 20	10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 20
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	12. Normative References . . . . . . . . . . . . . . . . . . . . . 23	12. Normative References . . . . . . . . . . . . . . . . . . . . . 23

	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

	1. Introduction	1. Introduction

	The Location-to-Service Translation (LoST) protocol [RFC5222] maps	The Location-to-Service Translation (LoST) protocol [RFC5222] maps
	service identifiers (URNs) and civic or geospatial information to	service identifiers (URNs) and civic or geospatial information to
	service URIs, based on service regions. While motivated by mapping	service URIs, based on service regions. While motivated by mapping
	locations to the public safety answering point (PSAP) serving that	locations to the public safety answering point (PSAP) serving that
	location, the protocol has been designed to generalize to other	location, the protocol has been designed to generalize to other
	location mapping services.	location mapping services.

	However, the current LoST query model assumes that each service URI	However, the current LoST query model assumes that each service URI
	has a service region and that service regions do not overlap. This	has a service region and that service regions do not overlap. This
	fits the emergency services model, where the service region of a PSAP	fits the emergency services model, where the service region of a PSAP
	is given by jurisdictional boundaries, but does not work as well for	is given by jurisdictional boundaries, but does not work as well for
	other services that do not have clearly defined boundaries. For	other services that do not have clearly defined boundaries. For
	example, any given location is likely served by a number of different	example, any given location is likely served by a number of different
	restaurants, depending on how far the prospective customer is willing	restaurants, depending on how far the prospective customer is willing

	to walk or drive.	to travel.

	We extend LoST with three additional <findService> query types,	We extend LoST with three additional <findService> query types,
	giving the protocol the ability to find the N nearest instances of a	giving the protocol the ability to find the N nearest instances of a
	particular service, all services within a given distance and all	particular service, all services within a given distance and all
	services whose service region includes the client's current location.	services whose service region includes the client's current location.

	2. Requirements Notation	2. Requirements Notation

	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

	skipping to change at page 7, line 22 ¶	skipping to change at page 7, line 22 ¶
	recursive="true">	recursive="true">
	<ext:region>false</ext:region>	<ext:region>false</ext:region>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>37.775 -122.422</gml:pos>	<gml:pos>37.775 -122.422</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	200	200
	</gs:radius>	</gs:radius>
	</gs:Circle>	</gs:Circle>
	</location>	</location>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 1: A 'within distance X' <findService> geodetic query using	Figure 1: A 'within distance X' <findService> geodetic query using

	the circular shape	the circular shape (a hypothetical service URN of
		"urn:service:food.pizza" is used)
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<findService	<findService
	xmlns="urn:ietf:params:xml:ns:lost1"	xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
	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"
	serviceBoundary="value"	serviceBoundary="value"
	recursive="true">	recursive="true">
	<ext:region>false</ext:region>	<ext:region>false</ext:region>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">

	skipping to change at page 8, line 27 ¶	skipping to change at page 8, line 27 ¶
	1235	1235
	</gs:semiMajorAxis>	</gs:semiMajorAxis>
	<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">	<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
	660	660
	</gs:semiMinorAxis>	</gs:semiMinorAxis>
	<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">	<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
	41.2	41.2
	</gs:orientation>	</gs:orientation>
	</gs:Ellipse>	</gs:Ellipse>
	</location>	</location>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 2: A 'within distance X' <findService> geodetic query using	Figure 2: A 'within distance X' <findService> geodetic query using

	the elliptical shape	the elliptical shape (a hypothetical service URN of
		"urn:service:food.pizza" is used)

	5.2. Queries Based on Service Regions	5.2. Queries Based on Service Regions

	As mentioned in Section 1, we can divide location-based services into	As mentioned in Section 1, we can divide location-based services into
	two main categories.	two main categories.

	Services based on:	Services based on:

	o how far they are from the user	o how far they are from the user


	skipping to change at page 10, line 35 ¶	skipping to change at page 10, line 35 ¶
	serviceBoundary="value" recursive="true">	serviceBoundary="value" recursive="true">
	<ext:region>true</ext:region>	<ext:region>true</ext:region>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>37.775 -122.422</gml:pos>	<gml:pos>37.775 -122.422</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	200	200
	</gs:radius>	</gs:radius>
	</gs:Circle>	</gs:Circle>
	</location>	</location>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 4 A 'served by' <findService> geodetic query with the new	Figure 4 A 'served by' <findService> geodetic query with the new

	<region> element	<region> element (a hypothetical service URN of
		"urn:service:food.pizza" is used)

	5.3. Difference Between "within distance X" and "served by" Queries	5.3. Difference Between "within distance X" and "served by" Queries

	Figures 1 and 4 show an example of a "within distance X" query and a	Figures 1 and 4 show an example of a "within distance X" query and a
	"served by" query, respectively. The two types of queries although	"served by" query, respectively. The two types of queries although
	very similar have three important differences.	very similar have three important differences.

	o A "served by" query can support all the shapes a "within distance	o A "served by" query can support all the shapes a "within distance
	X" query can support plus the point shape. The point shape does	X" query can support plus the point shape. The point shape does
	not make sense for a "within distance X" query and SHOULD NOT be	not make sense for a "within distance X" query and SHOULD NOT be

	skipping to change at page 11, line 37 ¶	skipping to change at page 11, line 38 ¶
	[RFC5222].	[RFC5222].

	Figures 5, 6 and 7 show a <findService> geodetic query where the	Figures 5, 6 and 7 show a <findService> geodetic query where the
	client asks the server to return no more than 20 service URIs. In	client asks the server to return no more than 20 service URIs. In
	particular, Figure 5 shows a 'N nearest' query, Figure 6 shows a	particular, Figure 5 shows a 'N nearest' query, Figure 6 shows a
	query which is a combination of 'N nearest' and 'within distance X'	query which is a combination of 'N nearest' and 'within distance X'
	while Figure 7 shows a query which is a combination of 'N nearest'	while Figure 7 shows a query which is a combination of 'N nearest'
	and 'served by'. When receiving such queries, the LoST server will	and 'served by'. When receiving such queries, the LoST server will
	return a list of no more than 20 points of interest.	return a list of no more than 20 points of interest.


	If the available points of interest are more than N, then the server	If the available points of interest are more than N, the server has
	has to identify among the points of interest to return, the N points	to identify, among those, the N points of interest closest to the
	of interest closest to the client's physical location and MUST return	client's physical location and MUST return those in the response.
	those in the response.

	When the <limit> element is not present in a <findService> query then	When the <limit> element is not present in a <findService> query then
	all available points of interest for the requested type of service	all available points of interest for the requested type of service
	SHOULD be returned by the LoST server. This behavior is consistent	SHOULD be returned by the LoST server. This behavior is consistent
	with [RFC5222].	with [RFC5222].

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<findService	<findService
	xmlns="urn:ietf:params:xml:ns:lost1"	xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"

	skipping to change at page 12, line 21 ¶	skipping to change at page 12, line 21 ¶
	<ext:limit>20</ext:limit>	<ext:limit>20</ext:limit>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">
	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>40.7128 -74.0092</gml:pos>	<gml:pos>40.7128 -74.0092</gml:pos>
	</gml:Point>	</gml:Point>
	</location>	</location>
	<service>urn:service:food.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 5: A 'N nearest' <findService> geodetic query with the new	Figure 5: A 'N nearest' <findService> geodetic query with the new

	<limit> element	<limit> element (a hypothetical service URN of
		"urn:service:food.pizza" is used)

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<findService	<findService
	xmlns="urn:ietf:params:xml:ns:lost1"	xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
	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"
	serviceBoundary="value"	serviceBoundary="value"
	recursive="true">	recursive="true">
	<ext:region>false</ext:region>	<ext:region>false</ext:region>
	<ext:limit>20</ext:limit>	<ext:limit>20</ext:limit>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>37.775 -122.422</gml:pos>	<gml:pos>37.775 -122.422</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	200	200
	</gs:radius>	</gs:radius>
	</gs:Circle>	</gs:Circle>
	</location>	</location>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 6: A <findService> geodetic query with the new <limit> and	Figure 6: A <findService> geodetic query with the new <limit> and
	<region> elements. This query is a combination of 'N nearest' and	<region> elements. This query is a combination of 'N nearest' and

	'within distance X' queries.	'within distance X' queries (a hypothetical service URN of
		"urn:service:food.pizza" is used)
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<findService	<findService
	xmlns="urn:ietf:params:xml:ns:lost1"	xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
	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"
	serviceBoundary="value"	serviceBoundary="value"
	recursive="true">	recursive="true">
	<ext:region>true</ext:region>	<ext:region>true</ext:region>
	<ext:limit>20</ext:limit>	<ext:limit>20</ext:limit>
	<location id="6020688f1ce1896d" profile="geodetic-2d">	<location id="6020688f1ce1896d" profile="geodetic-2d">
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>37.775 -122.422</gml:pos>	<gml:pos>37.775 -122.422</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
	100	100
	</gs:radius>	</gs:radius>
	</gs:Circle>	</gs:Circle>
	</location>	</location>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	</findService>	</findService>

	Figure 7: A <findService> geodetic query with the new <limit> and	Figure 7: A <findService> geodetic query with the new <limit> and
	<region> elements. This query is a combination of 'N nearest' and	<region> elements. This query is a combination of 'N nearest' and

	'served by' queries.	'served by' queries (a hypothetical service URN of
		"urn:service:food.pizza" is used)

	5.5. The <serviceLocation> Element in Responses	5.5. The <serviceLocation> Element in Responses

	It is important for the LoST client to know the location of a point	It is important for the LoST client to know the location of a point
	of interest so that distance, route and other metrics can be	of interest so that distance, route and other metrics can be
	computed. We introduce a new element, namely <serviceLocation>. The	computed. We introduce a new element, namely <serviceLocation>. The

	<serviceLocation> element contains the location of a point of service	<serviceLocation> element contains the location of a point of
	and SHOULD be used for all non-emergency services. When it is used,	service. When it is used, it MUST be contained in a <mapping>
	it MUST be contained in a <mapping> element. In responses such as	element. In responses such as <findServiceResponse> [RFC5222], a
	<findServiceResponse> [RFC5222], a list of service URIs, each with	list of service URIs, each with its own <serviceLocation> element,
	its own <serviceLocation> element, SHOULD be returned. The order of	SHOULD be returned. The order of service URIs in the list is not
	service URIs in the list is not relevant.	relevant.

	The <serviceLocation> element has one single attribute, 'profile', in	The <serviceLocation> element has one single attribute, 'profile', in
	order to specify the profile used. Both civic and geodetic profiles	order to specify the profile used. Both civic and geodetic profiles
	can be used. The geodetic profiles SHOULD be used in order to	can be used. The geodetic profiles SHOULD be used in order to
	compute distance, route and other metrics as at some point computing	compute distance, route and other metrics as at some point computing
	such metrics would require geocoding of the civic address in geodetic	such metrics would require geocoding of the civic address in geodetic
	coordinates. Because of this, the position specified in	coordinates. Because of this, the position specified in
	<serviceLocation> with a geodetic profile SHOULD be represented by	<serviceLocation> with a geodetic profile SHOULD be represented by
	using the <Point> element. The <Point> element is described in	using the <Point> element. The <Point> element is described in
	Section 12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491]. Figure	Section 12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491]. Figure

	skipping to change at page 14, line 44 ¶	skipping to change at page 14, line 45 ¶
	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"	xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
	xmlns:gml="http://www.opengis.net/gml">	xmlns:gml="http://www.opengis.net/gml">
	<mapping	<mapping
	expires="2007-01-01T01:44:33Z"	expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"	lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"	source="authoritative.example"
	sourceId="7e3f40b098c711dbb6060800200c9a66">	sourceId="7e3f40b098c711dbb6060800200c9a66">
	<displayName xml:lang="it">	<displayName xml:lang="it">
	Che bella pizza e all' anima da' pizza da Toto'	Che bella pizza e all' anima da' pizza da Toto'
	</displayName>	</displayName>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	<uri>sip:chebella@example.com</uri>	<uri>sip:chebella@example.com</uri>
	<uri>xmpp:chebella@example.com</uri>	<uri>xmpp:chebella@example.com</uri>
	<serviceNumber>2129397040</serviceNumber>	<serviceNumber>2129397040</serviceNumber>
	<ext:serviceLocation profile="geodetic-2d">	<ext:serviceLocation profile="geodetic-2d">
	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
	<gml:pos>33.665 -112.432</gml:pos>	<gml:pos>33.665 -112.432</gml:pos>


	</gml:Point>	</gml:Point>
	</ext:serviceLocation>	</ext:serviceLocation>
	<ext:serviceLocation profile="civic">	<ext:serviceLocation profile="civic">
	<civicAddress	<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>US</country>	<country>US</country>
	<A1>New York</A1>	<A1>New York</A1>
	<A3>New York</A3>	<A3>New York</A3>
	<A6>Broadway</A6>	<A6>Broadway</A6>
	<HNO>321</HNO>	<HNO>321</HNO>

	skipping to change at page 15, line 27 ¶	skipping to change at page 15, line 27 ¶
	</ext:serviceLocation>	</ext:serviceLocation>
	</mapping>	</mapping>
	<mapping	<mapping
	expires="2007-01-01T01:44:33Z"	expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"	lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"	source="authoritative.example"
	sourceId="7e3f40b098c711dbb6060800200c9b356">	sourceId="7e3f40b098c711dbb6060800200c9b356">
	<displayName xml:lang="en">	<displayName xml:lang="en">
	King Mario's Pizza	King Mario's Pizza
	</displayName>	</displayName>

	<service>urn:service:local.pizza</service>	<service>urn:service:food.pizza</service>
	<uri>sip:marios@example.com</uri>	<uri>sip:marios@example.com</uri>
	<uri>xmpp:marios@example.com</uri>	<uri>xmpp:marios@example.com</uri>
	<serviceNumber>2129397157</serviceNumber>	<serviceNumber>2129397157</serviceNumber>
	<ext:serviceLocation profile="geodetic-2d">	<ext:serviceLocation profile="geodetic-2d">
	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
	<gml:pos>33.683 -112.412</gml:pos>	<gml:pos>33.683 -112.412</gml:pos>
	</gml:Point>	</gml:Point>
	</ext:serviceLocation>	</ext:serviceLocation>
	<ext:serviceLocation profile="civic">	<ext:serviceLocation profile="civic">
	<civicAddress	<civicAddress

	skipping to change at page 17, line 5 ¶	skipping to change at page 17, line 7 ¶
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>37.775 -122.422</p2:pos>	<p2:pos>37.775 -122.422</p2:pos>
	</p2:Point>	</p2:Point>
	</location>	</location>
	<service>urn:service:sos.police</service>	<service>urn:service:sos.police</service>

	</findService>	</findService>

	Figure 9: A <findService> geodetic query for emergency services	Figure 9: A <findService> geodetic query for emergency services


		Unlike emergency services, where information such as service
		boundaries of PSAPs and locations of fire stations does not change
		very often, if at all, non-emergency services have information that
		may become inaccurate quickly. This is something implementers should
		take into account when designing applications for non-emergency
		location-based services.

	7. Relax NG Schema	7. Relax NG Schema

	This section provides the Relax NG schema of LoST extensions in the	This section provides the Relax NG schema of LoST extensions in the
	compact form. The verbose form is included in Section 9.	compact form. The verbose form is included in Section 9.

	namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"	namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
	default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"	default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"

	##	##
	## Extensions to the Location-to-Service Translation (LoST)	## Extensions to the Location-to-Service Translation (LoST)

	skipping to change at page 17, line 40 ¶	skipping to change at page 17, line 49 ¶
	limit=	limit=
	element limit {	element limit {
	xsd:positiveInteger	xsd:positiveInteger
	}	}
	}	}

	##	##
	## A boolean variable to request a search	## A boolean variable to request a search
	## based on either service areas or distance.	## based on either service areas or distance.
	##	##

		## NOTE: The W3C XML Schema has two different
		## lexical representations for boolean:

		## '1' or 'true' vs. '0' or 'false'.
		##
	div {	div {
	region=	region=
	element region {	element region {
	xsd:boolean	xsd:boolean
	}	}
	}	}

	##	##
	## Location Information	## Location Information
	##	##

	skipping to change at page 19, line 22 ¶	skipping to change at page 19, line 35 ¶
	the possibility of the Resolver getting overloaded by non-emergency	the possibility of the Resolver getting overloaded by non-emergency
	services queries, thus being unable to process emergency-service	services queries, thus being unable to process emergency-service
	queries. Such a situation can be addressed in more than one way.	queries. Such a situation can be addressed in more than one way.

	The obvious way to address this problem is to properly dimension the	The obvious way to address this problem is to properly dimension the
	LoST servers so to take into account also traffic for non-emergency	LoST servers so to take into account also traffic for non-emergency
	services. Given that the LoST server is an enhanced HTTP server,	services. Given that the LoST server is an enhanced HTTP server,
	properly dimensioning a deployment of LoST servers should not be very	properly dimensioning a deployment of LoST servers should not be very
	difficult to accomplish.	difficult to accomplish.


		The same security considerations as in [RFC5222] apply. In
		particular, in order to maintain integrity and confidentiality of
		requests and responses, Transport Layer Security (TLS) MUST be
		implemented and SHOULD be used as described in Sections 1, 14 and 18
		of [RFC5222].

	9. IANA Considerations	9. IANA Considerations

	9.1. LoST Extensions Relax NG Schema Registration	9.1. LoST Extensions Relax NG Schema Registration

	URI: urn:ietf:params:xml:schema:lost-ext	URI: urn:ietf:params:xml:schema:lost-ext

	Registrant Contact: Andrea G. Forte, forte@att.com; Henning	Registrant Contact: Andrea G. Forte, forte@att.com; Henning
	Schulzrinne, hgs@cs.columbia.edu	Schulzrinne, hgs@cs.columbia.edu


	Relax NG Schema: The Relax NG schema to be registered is contained in	Relax NG Schema: The Relax NG schema to be registered is contained in
	Section 6. Its first line is	Section 6. Its first line is

	default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"	default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"

	and its last line is	and its last line is

	}	}

	9.2. LoST Extensions Namespace Registration	9.2. LoST Extensions Namespace Registration

End of changes. 27 change blocks.
	34 lines changed or deleted	54 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/