GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6451

Internet Engineering Task Force (IETF) A. Forte Request for Comments: 6451 AT&T Category: Experimental H. Schulzrinne ISSN: 2070-1721 Columbia University

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

Abstract

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

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6451.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect

Forte & Schulzrinne Experimental [Page 1] RFC 6451 LoST Extensions December 2011

 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
 3.  Service Regions  . . . . . . . . . . . . . . . . . . . . . . .  3
 4.  New <findService> Query Types: "N nearest", "within
     distance X", and "served by" . . . . . . . . . . . . . . . . .  4
 5.  LoST Extensions  . . . . . . . . . . . . . . . . . . . . . . .  4
   5.1.  New Use of Shapes in Queries . . . . . . . . . . . . . . .  5
   5.2.  Queries Based on Service Regions . . . . . . . . . . . . .  7
   5.3.  Difference between "within distance X" and "served by"
         Queries  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.4.  Limiting the Number of Returned Service URIs . . . . . . . 10
   5.5.  The <serviceLocation> Element in Responses . . . . . . . . 12
 6.  Emergency Services . . . . . . . . . . . . . . . . . . . . . . 15
 7.  RELAX NG Schema  . . . . . . . . . . . . . . . . . . . . . . . 16
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.1.  LoST Extensions RELAX NG Schema Registration . . . . . . . 18
   9.2.  LoST Extensions Namespace Registration . . . . . . . . . . 19
 10. Non-Normative RELAX NG Schema in XML Syntax  . . . . . . . . . 19
 11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
 12. Normative References . . . . . . . . . . . . . . . . . . . . . 22

1. Introduction

 The Location-to-Service Translation (LoST) protocol [RFC5222] maps
 service identifiers (URNs) and civic or geospatial information to
 service URIs, based on service regions.  While motivated by mapping
 locations to the public safety answering point (PSAP) serving that
 location, the protocol has been designed to generalize to other
 location-mapping services.
 However, the current LoST query model assumes that each service URI
 has a service region and that service regions do not overlap.  This
 fits the emergency services model, where the service region of a PSAP
 is given by jurisdictional boundaries, but does not work as well for
 other services that do not have clearly defined boundaries.  For
 example, any given location is likely served by a number of different
 restaurants, depending on how far the prospective customer is willing
 to travel.

Forte & Schulzrinne Experimental [Page 2] RFC 6451 LoST Extensions December 2011

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

2. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

3. Service Regions

 Generally speaking, service regions apply only to a subset of
 services.
 In Section 1 of [RFC5222], a service region is defined as follows:
 "To minimize round trips and to provide robustness against network
 failures, LoST supports caching of individual mappings and indicates
 the region for which the same answer would be returned ("service
 region")."
 Section 5.5 of [RFC5222] further defines a service region:
 "A response MAY indicate the region for which the service URL
 returned would be the same as in the actual query, the so-called
 service region."
 For emergency services, service region and service area, as defined
 in [RFC5222], represent the same geographical area.  This is due to
 the fact that each PSAP serves its own area without overlapping with
 the service area of any other PSAP.  For as long as the client is
 located in the service area of a PSAP, the same PSAP is returned by
 the LoST server, that is, the service region does not change.  A
 service region is the service area of a PSAP.
 For non-emergency services, different points of service may have
 different overlapping service areas.  This means that one service
 region will probably include a large number of service areas.  Since
 we can get a large number of service URIs for each query, a service
 region per the definition above would be the region within which a
 user would get the same set of service URIs.  If one or more of the
 URIs in the set changes, the set of URIs changes, i.e., the service
 region changes.  Therefore, for non-emergency services, the service
 region defined in [RFC5222] would change frequently, thus greatly
 reducing the benefit of caching responses by service region.

Forte & Schulzrinne Experimental [Page 3] RFC 6451 LoST Extensions December 2011

 Generally speaking, we can divide location-based services into two
 main categories based on:
 o  how far they are from the user (e.g., automatic teller machine,
    food takeout);
 o  whether or not their service area includes the user's current
    location (e.g., pizza delivery, PSAP).
 For services included in the first category, service areas and
 therefore service regions are not relevant while they are important
 for services included in the second category.  This distinction
 becomes obvious if we consider, for example, the difference between
 takeout (first category) and delivery (second category).  In the case
 of takeout, the user wants to go to a particular restaurant and buy
 dinner, regardless of whether his location falls into the delivery
 service area of the restaurant or not.  For delivery, the user cares
 about the restaurant service area as the restaurant will deliver food
 to him only if his location falls within the restaurant service area.
 There is a clear distinction between services that require service
 areas and services that do not.  The LoST extensions defined in this
 document take this into account by using the service classification
 mentioned above.

4. New <findService> Query Types: "N nearest", "within distance X", and

  "served by"
 We introduce three new types of <findService> queries: "N nearest",
 "within distance X", and "served by".  The first query returns the N
 points of interest (POIs) closest to the client's physical location;
 the second query discovers all the points of interest located within
 a given distance from the client's physical location; and the third
 query returns all the points of interest whose service area includes
 the client's current location.

5. LoST Extensions

 For "within distance X" queries, the LoST client needs to specify to
 the server the range within which instances of a particular service
 should be searched.  In order to do this, we make use of various
 shapes [RFC5491] in LoST queries.
 For "served by" queries, the LoST client needs to let the server know
 that it MUST return only those services whose service area includes
 the user's current location.  In order to do this, we introduce the

Forte & Schulzrinne Experimental [Page 4] RFC 6451 LoST Extensions December 2011

 <region> element in <findService> queries.  Service region boundaries
 MAY be returned in a LoST <findServiceResponse> as described in
 [RFC5222].
 For "N nearest" queries, the LoST client needs to let the server know
 N, i.e., the maximum number of service URIs to be returned in a
 response.  In order to specify this, we introduce the <limit> element
 in <findService> queries.
 Also, we introduce a new element in LoST responses, namely
 <serviceLocation>.  This new element is used by the server to
 indicate to the client the physical location of points of interest.
 In doing so, the client can compute the distance and other metrics
 between its current location and the points of interest.
 The new elements <region>, <limit>, and <serviceLocation> are defined
 in the "lost-ext" namespace.  This new namespace is defined in
 Section 7.

5.1. New Use of Shapes in Queries

 In [RFC5491], different shapes are defined in order to represent a
 point and an area of uncertainty within which the user might be
 situated.  While this remains true for "served by" queries, for
 "within distance X" queries, such shapes can be interpreted as the
 area within which we want to find a service.  In particular, we want
 to search for points of service within that area because our location
 is within that area with a certain probability.  We can think of the
 area of uncertainty in a shape as the probability that a user might
 be within that area, so we want to look for services within that
 area.  Thus, the "within distance X" query manually sets the
 uncertainty in user location to an uncertainty shape with
 parameter X.
 For example, Figure 1 shows a "within distance X" <findService>
 geodetic query using the circular shape.  With the query shown in
 Figure 1, we are asking the LoST server to send us a list of service
 URIs for pizza places within 200 meters from our approximate position
 specified in <gml:pos>.

Forte & Schulzrinne Experimental [Page 5] RFC 6451 LoST Extensions December 2011

 <?xml version="1.0" encoding="UTF-8"?>
 <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   serviceBoundary="value"
   recursive="true">
   <ext:region>false</ext:region>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>37.775 -122.422</gml:pos>
       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
          200
       </gs:radius>
     </gs:Circle>
   </location>
   <service>urn:service:food.pizza</service>
 </findService>
 Figure 1: A "within distance X" <findService> geodetic query using
 the circular shape (a hypothetical service URN of
 "urn:service:food.pizza" is used)
 Aside from the circular shape, other shapes are also useful.  In
 particular, there are situations in which it is useful to query for
 services in a certain direction of movement rather than in an exact
 physical location.  For example, if a user is driving north from New
 York City to Boston, it would be useful for this user to be able to
 query for services north of where he currently is, that is, not at
 his current physical location nor at his final destination.
 In order to implement such direction-of-travel searches, this
 document supports the use of shapes such as an ellipse.  The ellipse
 has a major and a minor dimension, thus allowing for defining a
 "privileged" direction by having the major dimension in the direction
 of movement.  In the present context, the circular shape allows a
 device to search for services in any direction surrounding its
 physical location, while shapes such as the ellipse allow the device
 to search for services in a more specific direction.  Figure 2 shows
 a "within distance X" <findService> geodetic query using the
 elliptical shape.  The ellipse shape is defined in Section 5.2.4 of
 [RFC5491].

Forte & Schulzrinne Experimental [Page 6] RFC 6451 LoST Extensions December 2011

 <?xml version="1.0" encoding="UTF-8"?>
 <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   serviceBoundary="value"
   recursive="true">
   <ext:region>false</ext:region>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>42.5463 -73.2512</gml:pos>
       <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
         1235
       </gs:semiMajorAxis>
       <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
         660
       </gs:semiMinorAxis>
       <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
         41.2
       </gs:orientation>
     </gs:Ellipse>
   </location>
   <service>urn:service:food.pizza</service>
 </findService>
 Figure 2: A "within distance X" <findService> geodetic query using
 the elliptical shape (a hypothetical service URN of
 "urn:service:food.pizza" is used)

5.2. Queries Based on Service Regions

 As mentioned in Section 3, we can divide location-based services into
 two main categories based on:
 o  how far they are from the user;
 o  whether or not their service area includes the user's current
    location.
 A "within distance X" query addresses services included in the first
 category, while a "served by" query addresses services included in
 the second category.
 When querying LoST regarding a specific service, we need to specify
 if such service belongs to either the first or the second category.
 This is necessary since depending on the category to which the

Forte & Schulzrinne Experimental [Page 7] RFC 6451 LoST Extensions December 2011

 service belongs, the LoST server has to follow a different metric in
 selecting the results to include in the response.
 For example, Figure 3 shows three points of interest with their
 service areas.  The user location (i.e., the LoST client location) is
 represented by a circular shape (e.g., GPS).  If POI 1, POI 2, and
 POI 3 belong to the first category of service ("within distance X"
 query), their service area is irrelevant; what matters is how far
 they are from the user.  For such services, the shape representing
 the user location represents the distance within which the user wants
 to search for services (see Section 5.1).  In the example shown in
 Figure 3, the LoST server returns only POI 3, as POI 3 is the only
 point of interest falling within the user location represented by the
 circle, i.e., the area within which the user wants to search for
 services.  On the other hand, if the three points of service belong
 to the second category ("served by" query), then what matters is
 their service area.  In this second scenario, since the circle
 representing the user location overlaps with all three service areas,
 all three POIs can serve the location of the user, and the LoST
 server has to return all three POIs, that is, POI 1, POI 2, and
 POI 3.
                          __________________________
                          \    *****                \
          ,===============***====,    ***            \
         /              **  \   /         **          \
        /   POI 1     **     \ /            **         \
       /      o      **       X              **         \
      /             **       / \  USER        **         \
     /              **      /   \  0           **         \
    /               **     /     \      POI 3  **          \
   /                 **   /       \       o    **           \
  /          ,--------**-/---------\----------**--,          \
 `=====================**           \________**___|___________\
             |           **                **     |
             |   o         ***          ***       |
             |  POI 2           *****             |
             `------------------------------------'
 Figure 3: LoST client location (circle) overlapping three service
 areas of three different points of interest (POI 1, POI 2, POI 3)
 In order for the client to specify which of the two categories the
 service belongs to, we introduce the <region> element.  This new
 element is of type boolean.  When its value is false, the LoST server
 MUST perform a search based on the distance between the user and the
 points of service ("within distance X" query).  When its value is
 either true or the <region> element is missing (see Section 5.3), the

Forte & Schulzrinne Experimental [Page 8] RFC 6451 LoST Extensions December 2011

 requested service belongs to the second category, and a search based
 on service areas MUST be performed by the LoST server ("served by"
 query).  When present, the <region> element MUST be conveyed inside
 the <findService> element defined in [RFC5222].
 For a search based on service regions, the LoST server MUST return
 only those services whose service area includes the user's current
 location.  Service region boundaries MAY be returned in a LoST
 <findServiceResponse> as described in [RFC5222].
 <?xml version="1.0" encoding="UTF-8"?>
  <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   serviceBoundary="value" recursive="true">
   <ext:region>true</ext:region>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>37.775 -122.422</gml:pos>
       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
          200
       </gs:radius>
     </gs:Circle>
   </location>
  <service>urn:service:food.pizza</service>
 </findService>
 Figure 4: A "served by" <findService> geodetic query with the new
 <region> element (a hypothetical service URN of
 "urn:service:food.pizza" is used)

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

 Figures 1 and 4 show examples of a "within distance X" query and a
 "served by" query, respectively.  Although very similar, these two
 types of queries have three important differences:
 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
    not make sense for a "within distance X" query and SHOULD NOT be
    used for this query as it would be equivalent to a within-zero-
    meters search.
 o  In a "within distance X" query, we manually set the uncertainty
    level in user location to X, and we search for services within the
    area represented by such uncertain location.  In all other types

Forte & Schulzrinne Experimental [Page 9] RFC 6451 LoST Extensions December 2011

    of queries, including a "served by" query, the level of
    uncertainty in user location cannot be changed by the user, and a
    search based on service areas is performed.
 o  In a "within distance X" query, the value of the <region> element
    MUST be set to false.  A "served by" query SHALL have the value of
    the <region> element set to true.  If the <region> element is not
    present, its value MUST be assumed to be equal to true, and the
    query will be a "served by" query.  This behavior is consistent
    with [RFC5222].

5.4. Limiting the Number of Returned Service URIs

 Limiting the number of results is helpful, particularly for mobile
 devices with limited bandwidth.  For "N nearest" queries, the client
 needs to be able to tell the server to return no more than N service
 URIs.  In order to specify such a limit, we introduce a new element,
 namely <limit>.  This new element is OPTIONAL, but when present, it
 MUST be conveyed inside the <findService> element defined in
 [RFC5222].
 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
 particular, Figure 5 shows an "N nearest" query; Figure 6 shows a
 query that is a combination of "N nearest" and "within distance X";
 and Figure 7 shows a query that is a combination of "N nearest" and
 "served by".  When receiving such queries, the LoST server will
 return a list of no more than 20 points of interest.
 If the available points of interest are more than N, the server has
 to identify, among those, the N points of interest closest to the
 client's physical location and MUST return those in the response.
 When the <limit> element is not present in a <findService> query,
 then all available points of interest for the requested type of
 service SHOULD be returned by the LoST server.  This behavior is
 consistent with [RFC5222].

Forte & Schulzrinne Experimental [Page 10] RFC 6451 LoST Extensions December 2011

 <?xml version="1.0" encoding="UTF-8"?>
 <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   serviceBoundary="value" recursive="true">
   <ext:limit>20</ext:limit>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>40.7128 -74.0092</gml:pos>
     </gml:Point>
   </location>
 <service>urn:service:food.pizza</service>
 </findService>
 Figure 5: An "N nearest" <findService> geodetic query with the new
 <limit> element (a hypothetical service URN of
 "urn:service:food.pizza" is used)
 <?xml version="1.0" encoding="UTF-8"?>
 <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   serviceBoundary="value"
   recursive="true">
   <ext:region>false</ext:region>
   <ext:limit>20</ext:limit>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>37.775 -122.422</gml:pos>
       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
          200
       </gs:radius>
     </gs:Circle>
   </location>
   <service>urn:service:food.pizza</service>
 </findService>
 Figure 6: A <findService> geodetic query with the new <limit> and
 <region> elements.  This query is a combination of the "N nearest"
 and "within distance X" queries (a hypothetical service URN of
 "urn:service:food.pizza" is used)

Forte & Schulzrinne Experimental [Page 11] RFC 6451 LoST Extensions December 2011

 <?xml version="1.0" encoding="UTF-8"?>
 <findService
   xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:gs="http://www.opengis.net/pidflo/1.0"
   serviceBoundary="value"
   recursive="true">
   <ext:region>true</ext:region>
   <ext:limit>20</ext:limit>
   <location id="6020688f1ce1896d" profile="geodetic-2d">
     <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
       <gml:pos>37.775 -122.422</gml:pos>
       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
          100
       </gs:radius>
     </gs:Circle>
   </location>
   <service>urn:service:food.pizza</service>
 </findService>
 Figure 7: A <findService> geodetic query with the new <limit> and
 <region> elements.  This query is a combination of the "N nearest"
 and "served by" queries (a hypothetical service URN of
 "urn:service:food.pizza" is used)

5.5. The <serviceLocation> Element in Responses

 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
 computed.  We introduce a new element, namely <serviceLocation>.  The
 <serviceLocation> element contains the location of a point of
 service.  When it is used, it MUST be contained in a <mapping>
 element.  In responses such as <findServiceResponse> [RFC5222], a
 list of service URIs, each with its own <serviceLocation> element,
 SHOULD be returned.  The order of service URIs in the list is not
 significant.
 The <serviceLocation> element has a single attribute, "profile", that
 specifies the profile used.  Both civic and geodetic profiles can be
 used.  The geodetic profiles SHOULD be used in order to compute
 distance, route, and other metrics as, at some point, computing such
 metrics would require geocoding of the civic address in geodetic
 coordinates.  Because of this, the position specified in
 <serviceLocation> with a geodetic profile SHOULD be represented by
 the <Point> element.  The <Point> element is described in Section

Forte & Schulzrinne Experimental [Page 12] RFC 6451 LoST Extensions December 2011

 12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491].  Figure 8 shows
 a <findServiceResponse> answer containing two location-to-service-URI
 mappings.
 [NOTE: The <locationUsed> element cannot be extended for this
 purpose, as it is defined outside of the <mapping> element.  In
 particular, in a response, the <locationUsed> element is always one,
 while the number of service URIs is typically more than one.]
 There are situations, however, in which it is helpful to include a
 civic address together with the geodetic coordinates of a point of
 service.  Usually, databases already contain the civic address of
 points of interest, and for devices with limited capabilities, it is
 not always possible to perform decoding of geocoordinates in order to
 determine the civic address.  Because of this, including the civic
 address in a response can be useful.  In order to do this, we use a
 civic profile for the <serviceLocation> element and specify the POI
 civic address in a <civicAddress> element contained in the
 <serviceLocation> element.  The basic civic location profile is
 defined in Section 12.3 of [RFC5222].
 Per [RFC5139], it is RECOMMENDED to use multiple <serviceLocation>
 elements when multiple forms of service location are available, and
 it is RECOMMENDED to provide a geodetic form whenever possible.  When
 multiple <serviceLocation> elements are present for one POI, all of
 them MUST be contained in the same <mapping> element, that is, the
 <mapping> element for that POI.  Figure 8 shows a
 <findServiceResponse> answer with both geodetic and civic locations.
    <?xml version="1.0" encoding="UTF-8"?>
    <findServiceResponse
      xmlns="urn:ietf:params:xml:ns:lost1"
      xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
      xmlns:gml="http://www.opengis.net/gml">
      <mapping
        expires="2007-01-01T01:44:33Z"
        lastUpdated="2006-11-01T01:00:00Z"
        source="authoritative.example"
        sourceId="7e3f40b098c711dbb6060800200c9a66">
        <displayName xml:lang="it">
          Che bella pizza e all' anima da' pizza da Toto'
        </displayName>
        <service>urn:service:food.pizza</service>
        <uri>sip:chebella@example.com</uri>
        <uri>xmpp:chebella@example.com</uri>
        <serviceNumber>2129397040</serviceNumber>
        <ext:serviceLocation profile="geodetic-2d">
          <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">

Forte & Schulzrinne Experimental [Page 13] RFC 6451 LoST Extensions December 2011

            <gml:pos>33.665 -112.432</gml:pos>
          </gml:Point>
        </ext:serviceLocation>
        <ext:serviceLocation profile="civic">
          <civicAddress
              xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
              <country>US</country>
              <A1>New York</A1>
              <A3>New York</A3>
              <A6>Broadway</A6>
              <HNO>321</HNO>
              <PC>10027</PC>
          </civicAddress>
        </ext:serviceLocation>
      </mapping>
      <mapping
        expires="2007-01-01T01:44:33Z"
        lastUpdated="2006-11-01T01:00:00Z"
        source="authoritative.example"
        sourceId="7e3f40b098c711dbb6060800200c9b356">
        <displayName xml:lang="en">
          King Mario's Pizza
        </displayName>
        <service>urn:service:food.pizza</service>
        <uri>sip:marios@example.com</uri>
        <uri>xmpp:marios@example.com</uri>
        <serviceNumber>2129397157</serviceNumber>
        <ext:serviceLocation profile="geodetic-2d">
          <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
            <gml:pos>33.683 -112.412</gml:pos>
          </gml:Point>
        </ext:serviceLocation>
        <ext:serviceLocation profile="civic">
          <civicAddress
              xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
              <country>US</country>
              <A1>New York</A1>
              <A3>New York</A3>
              <A6>Amsterdam Avenue</A6>
              <HNO>123</HNO>
              <PC>10027</PC>
          </civicAddress>
        </ext:serviceLocation>
      </mapping>
      <path>
        <via source="resolver.example"/>
        <via source="authoritative.example"/>
      </path>

Forte & Schulzrinne Experimental [Page 14] RFC 6451 LoST Extensions December 2011

      <locationUsed id="6020688f1ce1896d"/>
    </findServiceResponse>
 Figure 8: A <findServiceResponse> answer

6. Emergency Services

 The LoST extensions defined in this document SHOULD NOT be used when
 routing emergency sessions, as there may be LoST servers that do not
 support these extensions.
 Figure 9 shows a <findService> query for emergency services as
 defined in [RFC5222].  In such a query, both the <region> element and
 the <limit> element are missing.  According to the LoST extensions
 defined in this document, when the <region> element is missing, its
 value defaults to true, and the query is a "served by" query (see
 Section 5.3).  When the <limit> element is missing, no limit is
 specified, that is, the LoST server can return any number of results
 (see Section 5.4).  This behavior is consistent with [RFC5222] so
 that PSAPs are selected according to their service area, and when a
 user's location overlaps multiple service areas, the LoST server MAY
 return multiple PSAPs.
 The LoST extensions defined in this document are consistent with the
 behavior defined in [RFC5222], and, as such, they do not modify LoST
 behavior for emergency services.
 <?xml version="1.0" encoding="UTF-8"?>
    <findService
      xmlns="urn:ietf:params:xml:ns:lost1"
      xmlns:p2="http://www.opengis.net/gml"
      serviceBoundary="value"
      recursive="true">
      <location id="6020688f1ce1896d" profile="geodetic-2d">
        <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
           <p2:pos>37.775 -122.422</p2:pos>
        </p2:Point>
      </location>
      <service>urn:service:sos.police</service>
    </findService>
 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

Forte & Schulzrinne Experimental [Page 15] RFC 6451 LoST Extensions December 2011

 may become inaccurate quickly.  Implementers should take this into
 account when designing applications for non-emergency location-based
 services.

7. RELAX NG Schema

 This section provides the RELAX NG schema of LoST extensions in the
 compact form.  The verbose form is included in Section 9.
 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
 default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
 ##
 ##    Extensions to the Location-to-Service Translation (LoST)
 ##    Protocol
 ##
 ##    LoST Extensions define three new elements: limit, region, and
 ##    serviceLocation.
 ##
 start =
   limit
   | region
   | serviceLocation
 ##
 ##    A limit to the number of returned results.
 ##
 div {
   limit=
     element limit {
       xsd:positiveInteger
     }
 }
 ##
 ##   A boolean variable to request a search
 ##   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 {
   region=
     element region {
       xsd:boolean
     }

Forte & Schulzrinne Experimental [Page 16] RFC 6451 LoST Extensions December 2011

 }
 ##
 ##    Location Information
 ##
 div {
   locationInformation =
     extensionPoint+,
     attribute profile { xsd:NMTOKEN }?
 }
 ##
 ##    Location Information about the returned point
 ##    of service.
 ##
 div {
   serviceLocation=
     element serviceLocation { locationInformation }+
 }
 ##
 ##    Patterns for inclusion of elements from schemas in
 ##    other namespaces.
 ##
 div {
   ##
   ##    Any element not in the LoST Extensions
   ##    namespace.
   ##
   notLostExt = element * - (ns1:* | ns1:*) { anyElement }
   ##
   ##    A wildcard pattern for including any element
   ##    from any other namespace.
   ##
   anyElement =
     (element * { anyElement }
      | attribute * { text }
      | text)*
   ##
   ##    A point where future extensions
   ##    (elements from other namespaces)
   ##    can be added.
   ##
   extensionPoint = notLostExt*
 }

Forte & Schulzrinne Experimental [Page 17] RFC 6451 LoST Extensions December 2011

8. Security Considerations

 The overall LoST architecture and framework are defined in [RFC5582].
 All LoST queries for both emergency and non-emergency services, if
 not cached, are sent from the LoST client to a first-hop LoST server.
 In [RFC5582] terminology, a LoST client is called Seeker, and the
 first-hop LoST server is called Resolver (for more rigorous
 definitions, please refer to [RFC5582]).  The Resolver will contact
 other LoST servers, and eventually an authoritative LoST server will
 be found.  A response will then be sent back to the Seeker.
 When considering both emergency and non-emergency services, there is
 the possibility of the Resolver getting overloaded by non-emergency-
 service queries, thus being unable to process emergency-service
 queries.  Such a situation can be addressed in several ways.  For
 example, the service provider could dimension the LoST server to
 accommodate anticipated combined traffic loads and then give priority
 to emergency service requests during overload situations, possibly
 with the help of HTTP load balancers.
 The security considerations 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.1. LoST Extensions RELAX NG Schema Registration

 URI: urn:ietf:params:xml:schema:lost-ext
 Registrant Contact: Andrea G. Forte, forte@att.com;
 Henning Schulzrinne, hgs@cs.columbia.edu
 RELAX NG Schema: The RELAX NG schema to be registered is contained in
 Section 7.  Its first line is
 default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
 and its last line is
 }

Forte & Schulzrinne Experimental [Page 18] RFC 6451 LoST Extensions December 2011

9.2. LoST Extensions Namespace Registration

 URI: urn:ietf:params:xml:ns:lost-ext
 Registrant Contact: Andrea G. Forte, forte@att.com;
 Henning Schulzrinne, hgs@cs.columbia.edu
 XML:
 BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
   "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
   <meta http-equiv="content-type"
         content="text/html;charset=iso-8859-1"/>
   <title>LoST Extensions Namespace</title>
 </head>
 <body>
   <h1>Namespace for LoST Extensions</h1>
   <h2>urn:ietf:params:xml:ns:lost-ext</h2>
 <p>See <a href="http://www.rfc-editor.org/rfc/rfc6451.txt">
    RFC 6451</a>.</p>
 </body>
 </html>
 END

10. Non-Normative RELAX NG Schema in XML Syntax

<?xml version="1.0" encoding="UTF-8"?>

 <grammar ns="urn:ietf:params:xml:ns:lost-ext"
         xmlns="http://relaxng.org/ns/structure/1.0"
         xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
         <start>
     <a:documentation>
       Extensions to the Location-to-Service Translation (LoST)
       Protocol.
       LoST Extensions define three new elements: limit, region and
       serviceLocation.
     </a:documentation>
     <choice>
       <ref name="limit"/>
       <ref name="region"/>
       <ref name="serviceLocation"/>
     </choice>

Forte & Schulzrinne Experimental [Page 19] RFC 6451 LoST Extensions December 2011

         </start>
   <div>
     <a:documentation>
       A limit to the number of returned results.
     </a:documentation>
     <define name="limit">
       <element name="limit">
         <data type="positiveInteger"/>
       </element>
     </define>
   </div>
  <div>
    <a:documentation>
      A boolean variable to request a search
      based on either service areas or distance.
    </a:documentation>
    <define name="region">
      <element name="region">
        <data type="boolean"/>
      </element>
    </define>
  </div>
   <div>
     <a:documentation>
       Location Information
     </a:documentation>
     <define name="locationInformation">
       <oneOrMore>
         <ref name="extensionPoint"/>
       </oneOrMore>
       <optional>
         <attribute name="profile">
           <data type="NMTOKEN"/>
         </attribute>
       </optional>
     </define>
   </div>
   <div>
     <a:documentation>
       Location Information about the returned point of service.
     </a:documentation>

Forte & Schulzrinne Experimental [Page 20] RFC 6451 LoST Extensions December 2011

     <define name="serviceLocation">
       <element name="serviceLocation">
           <ref name="locationInformation"/>
       </element>
     </define>
   </div>
   <div>
     <a:documentation>
       Patterns for inclusion of elements from schemas in
       other namespaces.
     </a:documentation>
     <define name="notLostExt">
       <a:documentation>
         Any element not in the LoST Extensions namespace.
       </a:documentation>
       <element>
         <anyName>
           <except>
             <nsName ns="urn:ietf:params:xml:ns:lost-ext"/>
             <nsName/>
           </except>
         </anyName>
         <ref name="anyElement"/>
       </element>
     </define>
     <define name="anyElement">
       <a:documentation>
         A wildcard pattern for including any element
         from any other namespace.
       </a:documentation>
       <zeroOrMore>
         <choice>
           <element>
             <anyName/>
             <ref name="anyElement"/>
           </element>
           <attribute>
             <anyName/>
           </attribute>
           <text/>
         </choice>
       </zeroOrMore>
     </define>
     <define name="extensionPoint">

Forte & Schulzrinne Experimental [Page 21] RFC 6451 LoST Extensions December 2011

       <a:documentation>
         A point where future extensions
         (elements from other namespaces)
         can be added.
       </a:documentation>
       <zeroOrMore>
         <ref name="notLostExt"/>
       </zeroOrMore>
     </define>
   </div>
</grammar>

11. Acknowledgments

 We would like to thank Shida Schubert for reviewing an early version
 of this document.  We also appreciate the suggestions from members of
 the ECRIT working group.  In particular, we are grateful to Richard
 L. Barnes, Robert Sparks, and Martin Thomson for their overall
 feedback and for their comments on how non-emergency services may
 affect the provisioning of emergency services lookups.

12. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
            Tschofenig, "LoST: A Location-to-Service Translation
            Protocol", RFC 5222, August 2008.
 [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
            Format for Presence Information Data Format Location
            Object (PIDF-LO)", RFC 5139, February 2008.
 [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
            Presence Information Data Format Location Object (PIDF-LO)
            Usage Clarification, Considerations, and Recommendations",
            RFC 5491, March 2009.
 [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
            Framework", RFC 5582, September 2009.

Forte & Schulzrinne Experimental [Page 22] RFC 6451 LoST Extensions December 2011

Authors' Addresses

 Andrea G. Forte
 AT&T
 Security Research Center
 33 Thomas Street
 New York, NY  10007
 USA
 EMail: forte@att.com
 Henning Schulzrinne
 Columbia University
 Department of Computer Science
 1214 Amsterdam Avenue, MC 0401
 New York, NY  10027
 USA
 EMail: hgs@cs.columbia.edu

Forte & Schulzrinne Experimental [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6451.txt · Last modified: 2011/12/08 19:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki