[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04                                                
ECRIT                                                        R. Marshall
Internet-Draft                                                 J. Martin
Intended status: Informational                                       TCS
Expires: August 5, 2011                                    February 2011


      A LoST extension to support return of similar location info
                draft-marshall-ecrit-similar-location-00











































Marshall & Martin        Expires August 5, 2011                 [Page 1]


Internet-Draft     Similar Location Extension to LoST      February 2011


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.








































Marshall & Martin        Expires August 5, 2011                 [Page 2]


Internet-Draft     Similar Location Extension to LoST      February 2011


Abstract

   This document introduces a new way to return similar civic locations
   (i.e., address sets) when original input location is returned not
   valid within the findServiceResponse message.  This document defines
   a new extension to the findServiceResponse message within the LoST
   protocol [RFC5222], that enables the LoST protocol to return one or
   more suggested sets of civic location information.  This "similar"
   address information is included as compilation of ca type xml
   elements within the existing response message structure.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 5, 2011.

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
   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.









Marshall & Martin        Expires August 5, 2011                 [Page 3]


Internet-Draft     Similar Location Extension to LoST      February 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview of Location Transformation  . . . . . . . . . . . . .  7
   4.  Similar Location Example in findServiceResponse  . . . . . . .  8
   5.  Precedent for Similar Address Services . . . . . . . . . . . . 10
   6.  Similar Address Input Parameters . . . . . . . . . . . . . . . 11
   7.  Errors and Warnings  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Relax NG schema Impacts  . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . 17
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18


































Marshall & Martin        Expires August 5, 2011                 [Page 4]


Internet-Draft     Similar Location Extension to LoST      February 2011


1.  Introduction

   The LoST protcol [RFC5222] supports the validation of civic location
   information as input, by providing a set of validation result status
   indicators.  The current usefullness of the supported xml elements,
   "valid", "invalid", and "unchecked", is limited, because while they
   each provide an indication of validity for any one element as a part
   of the whole address, the mechanism is insufficient in providing
   hints or alternate suggestions as to other close fits, or similar
   civic locations.

   As with the example below, a civic location that is input for
   validation using an incorrect street suffix will result in an invalid
   civic location.  This document provides a mechanism to provide
   additional clues, and suggestions for addresses that are very similar
   to the original.

   This enhancement to the validation within LoST is required to ensure
   a high level of address matching, to overcome user and system input
   errors, and to support the usefullness of location-based systems in
   general.

   The structure of this document includes terminology, Section 2,
   followed by a discussion of the basic elements involved in location
   validation.  These use of these elements, by way of example, is
   discussed in an overview section, Section 3, with accompanying
   rationale, and a brief discussion of the impacts to LoST, and its
   current schema.























Marshall & Martin        Expires August 5, 2011                 [Page 5]


Internet-Draft     Similar Location Extension to LoST      February 2011


2.  Terminology

   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 RFC 2119 [RFC2119],
   with the important qualification that, unless otherwise stated, these
   terms apply to the design of the Location Configuration Protocol and
   the Location Dereferencing Protocol, not its implementation or
   application.

   The following terms are defined in this document:

   Address:  The term Address is used interchangeably with the concept
      of Civic Location.

   Invalid:  The result of the attempt to match an individual input data
      as part of a larger set of data that has already been successfully
      matched.

   Invalid Civic Element:  An unmatched result of an individual civic
      location element as part of a broader set of elements that make up
      a civic location.

   Invalid Civic Location:  An unmatched result of an input civic
      location, when taken as a whole, based on one or more individual
      unmatched civic address elements.

   Similar Address:  A suggested civic location that is comparitively
      close to the civic location which was input, but which had one or
      more invalid element.





















Marshall & Martin        Expires August 5, 2011                 [Page 6]


Internet-Draft     Similar Location Extension to LoST      February 2011


3.  Overview of Location Transformation

   This section lays out an example of how similar addresses are shown
   to work.

   Suppose that someone submits this address to Lost: 6000 15th Ave
   Seattle, WA This address is deemed "invalid" because there is no
   plain "15th Ave" in the city of Seattle with a house number equal to
   6000.  However there are two addresses within the address dataset
   that are "similar", when all parts of the address are taken as a
   whole.  These similar addresses that could be suggested to the user
   are as follows: similar address #1: 6000 15th Ave NW Seattle, WA
   98107 similar address #2: 6000 15th Ave NE Seattle, WA 98105 This
   document proposes to include the above similar addresses as
   civicAddress elements in the response to locationValidation.  The
   next section shows the LoST request and response xml message fragment
   for the above example, returning the "similar" addresses:


































Marshall & Martin        Expires August 5, 2011                 [Page 7]


Internet-Draft     Similar Location Extension to LoST      February 2011


4.  Similar Location Example in findServiceResponse

   The LoST server knows the data that is available internally, and can
   choose which type of similar addresses that it wants to return.


   <!-- =============================================== -->


   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     validateLocation="true">

     <location id="587cd3880" profile="civic">
       <civicAddress
         xmlns="urn:ietf:params:mxl:ns:pidf:geopriv10:civicAddr">

         <country>US</country>
         <A1>WA</A1>
         <A3>Seattle</A3>
         <A6>15th Ave</A6>
         <HNO>6000</HNO>

       </civicAddress>
     </location>

     <service>urn:service:sos</service>

   </findService>


   <!-- =============================================== -->


   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" >

     <mapping
       expires="NO-CACHE"
       lastUpdated="2006-11-01T01:00:00Z"
       source="authoritative.example"
       sourceId="8799e346000098aa3e">

       <displayName xml:lang="en">Seattle 911</displayName>
       <service>urn:service:sos</service>
       <uri>sip:seattle-911@example.com</uri>
       <serviceNumber>911</serviceNumber>

     </mapping>




Marshall & Martin        Expires August 5, 2011                 [Page 8]


Internet-Draft     Similar Location Extension to LoST      February 2011


     <locationValidation
       xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

       <valid>ca:country ca:A1 ca:A3</valid>
       <invalid>ca:A6</invalid>
       <unchecked>ca:HNO</unchecked>

       <ca:civicAddress>  <!-- "similar" address #1 -->
         <ca:country>US</ca:country>
         <ca:A1>WA</ca:A1>
         <ca:A3>SEATTLE</ca:A3>
         <ca:RD>15TH</ca:RD>
         <ca:STS>AVE</ca:STS>
         <ca:POD>NW</ca:POD>
         <ca:HNO>6000</ca:HNO>
         <ca:PC>98107</ca:PC>
         <ca:PCN>SEATTLE</ca:PCN>
       </ca:civicAddress>

       <ca:civicAddress>  <!-- "similar" address #2 -->
         <ca:country>US</ca:country>
         <ca:A1>WA</ca:A1>
         <ca:A3>SEATTLE</ca:A3>
         <ca:RD>15TH</ca:RD>
         <ca:STS>AVE</ca:STS>
         <ca:POD>NE</ca:POD>
         <ca:HNO>6000</ca:HNO>
         <ca:PC>98105</ca:PC>
         <ca:PCN>SEATTLE</ca:PCN>
       </ca:civicAddress>

     </locationValidation>

     <path>
       <via source="authoritative.example"/>
     </path>

     <locationUsed id="587cd3880"/>

   </findServiceResponse>


   <!-- =============================================== -->








Marshall & Martin        Expires August 5, 2011                 [Page 9]


Internet-Draft     Similar Location Extension to LoST      February 2011


5.  Precedent for Similar Address Services

   There are many web-based applications that already use address
   matching to refine user input when the exact address is not known -
   or is represented in a way that is not commonly known or familiar.

   One example is a public transportation system that offers a trip
   planner application, but requires a start and end address to be able
   to determine a route.  In some cases, the seekers of the route
   information are the ones with the least familiarity with the region,
   so having the ability to obtain similar addresses would be beneficial
   to the user.

   Another example is Public Safety.  Next Generation emergency call
   architectures have founded on the IETF's ECRIT LoST protocol, which
   makes the need to assure that the call routing mechanism will work.
   LoST can take advantage of this proposal during location validation
   step, ahead of an emergency call, to assure the user (or LoST
   client), their emergency call witll route appropriately, and that
   they will have the correctly selected dispatch location used.































Marshall & Martin        Expires August 5, 2011                [Page 10]


Internet-Draft     Similar Location Extension to LoST      February 2011


6.  Similar Address Input Parameters

   Additional input parameters that request the server to return a
   greater number of similar addresses, or specify the type(s) of data
   to substitute (i.e., a matching algorithm), is left as out-of-scope
   in this draft.













































Marshall & Martin        Expires August 5, 2011                [Page 11]


Internet-Draft     Similar Location Extension to LoST      February 2011


7.  Errors and Warnings

   [This section to be supplied]
















































Marshall & Martin        Expires August 5, 2011                [Page 12]


Internet-Draft     Similar Location Extension to LoST      February 2011


8.  Relax NG schema Impacts

   The above proposal is already compatible with RFC-5222 RELAX NG
   definition for the <locationValidation> element, based on the
   inclusion in the locationValidation definition of "extensionPoint",
   which allows for the inclusion of any non-LoST elements.

   The proposal does not, therefore, need to redefine the current RFC-
   5222 RELAX NG definitions, the proposal simply needs to say that when
   a LoST Server returns a <findServiceResponse> with a
   locationValidation that contains an invalid, it is recommended that
   the LoST server try to include one or more <civicAddress> in the
   <locationValidation>, where each is a fully valid address that is
   "similar" to the input address.  User-facing GUIs should present
   these "similar" addresses to help the user resolve the invalid
   address in their original request.

   The proposal does not try and define exactly how to compute "similar"
   addresses.  Lost server implementers are free to choose whatever
   technique to compute similar addresses -- any "similar" address is
   likely to be helpful for the user.






























Marshall & Martin        Expires August 5, 2011                [Page 13]


Internet-Draft     Similar Location Extension to LoST      February 2011


9.  Security Considerations

   [This section to be supplied]
















































Marshall & Martin        Expires August 5, 2011                [Page 14]


Internet-Draft     Similar Location Extension to LoST      February 2011


10.  IANA Considerations

   [This section to be supplied]
















































Marshall & Martin        Expires August 5, 2011                [Page 15]


Internet-Draft     Similar Location Extension to LoST      February 2011


11.  Acknowledgements

   [This section to be supplied]
















































Marshall & Martin        Expires August 5, 2011                [Page 16]


Internet-Draft     Similar Location Extension to LoST      February 2011


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References











































Marshall & Martin        Expires August 5, 2011                [Page 17]


Internet-Draft     Similar Location Extension to LoST      February 2011


Authors' Addresses

   Roger Marshall
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   Phone: +1 206 792 2424
   Email: rmarshall@telecomsys.com
   URI:   http://www.telecomsys.com


   Jeff Martin
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   Phone: +1 206 792 2584
   Email: jmartin@telecomsys.com
   URI:   http://www.telecomsys.com



























Marshall & Martin        Expires August 5, 2011                [Page 18]