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

Versions: 00 01 02 03 04                                                
ECRIT                                                        R. Marshall
Internet-Draft                                                 J. Martin
Intended status: Standards Track                                     TCS
Expires: January 13, 2012                                       B. Rosen
                                                                 Neustar
                                                           July 12, 2011


A LoST extension to support return of complete and similar location info
                draft-marshall-ecrit-similar-location-01









































Marshall, et al.        Expires January 13, 2012                [Page 1]


Internet-Draft    Returned Location Extensions to LoST         July 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, et al.        Expires January 13, 2012                [Page 2]


Internet-Draft    Returned Location Extensions to LoST         July 2011


Abstract

   This document introduces a new way to provide returned location
   information in LoST responses that is either of a completed or
   similar form to the original input civic location, based on whether a
   valid or invalid location is returned 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 a completed civic location
   element set for a valid response, and one or more suggested sets of
   civic location information for invalid LoST responses.  These two
   types of civic addresses are referred to as either "complete" or
   "similar" locations, and are 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 January 13, 2012.

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, et al.        Expires January 13, 2012                [Page 3]


Internet-Draft    Returned Location Extensions to LoST         July 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview of Returned Location Information  . . . . . . . . . .  7
   4.  Returned Location Information  . . . . . . . . . . . . . . . .  9
   5.  Complete Location returned for Valid response  . . . . . . . . 10
   6.  Similar Location returned for Invalid Response . . . . . . . . 12
   7.  Relax NG schema  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 19
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20



































Marshall, et al.        Expires January 13, 2012                [Page 4]


Internet-Draft    Returned Location Extensions to LoST         July 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
   either the complete set of address elements that the LoST server
   contains, or of providing alternate suggestions (hints) as to which
   civic address is intended.

   Whether the input civic location is valid and missing information, or
   invalid due to missing or wrong information during input, this
   document provides a mechanism to return full address information for
   those valid or invalid cases.

   This enhancement to the validation feature within LoST is required in
   order 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, et al.        Expires January 13, 2012                [Page 5]


Internet-Draft    Returned Location Extensions to LoST         July 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.

   Complete Location:  An expanded civic location that includes
      additional address elements in addition to the existing validated
      civic elements provided.

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

   Returned Location Information:  A set of standard civic location
      elements returned in a LoST response.














Marshall, et al.        Expires January 13, 2012                [Page 6]


Internet-Draft    Returned Location Extensions to LoST         July 2011


3.  Overview of Returned Location Information

   This document describes an extension to LoST [RFC5222], to allow
   additional location information to be returned in a
   findServiceResponse for two different use cases.

   Since a LoST server often contains more data than what is often
   included within a findService request, it is expected that this
   additional location information could be returned within response
   messages that may be both valid and invalid.  For valid responses,
   where a LoST server contains additional location information relating
   to that civic address, the findServiceResponse message can return
   additional location information along with the original validated
   elements in order to form a complete civic location.

   On the other hand, for an invalid LoST response that contains address
   elements returned with one or more of them marked as invalid, and
   constituting an invalid location, this document introduces the idea
   of reusing this same mechanism, but for a different purpose - to
   supply similar location information - again, information that is
   contained within the LoST server, but is provided as a complete
   "similar" civic location put forward as a suggested alternative
   address that is also a valid location.

   In valid location responses, this works in the following way: when a
   LoST server returns a response to a findService request that contains
   a set of CAtype elements considered valid, the location information
   in the findServiceResponse is extended to include additional location
   information specific for that location.  As an example, the query may
   contain a HNO (house number), RD (road name) and A3 (city) but may
   not contain A1, A2, PC (Postal Code) CAtypes.  The RD and PC elements
   may be sufficient to locate the address specified in the request and
   thus be considered valid.  Yet, downstream entities may find it
   helpful to have the additional A1, A2, and PC location elements that
   exist, and so the mechanism described here supports their inclusion.
   Since [RFC5222] currently does not have a way for this additional
   location information to be returned in the findServiceResponse, this
   document extends RFC5222 so that it can include a completeLocation
   element within the findServiceResponse message, representing a
   "complete" civic location.

   input address: 6000 15th Ave NW Seattle

   completed address: 6000 15th Ave NW Seattle, WA 98105 US

   When invalid location responses are received, the same mechanism
   works as follows: when a LoST server returns a response to a
   findService request that contains a set of CAtype elements with one



Marshall, et al.        Expires January 13, 2012                [Page 7]


Internet-Draft    Returned Location Extensions to LoST         July 2011


   or more that are tagged as invalid, the location information in the
   findServiceResponse is extended to include additional location
   information specific for that location.  Differing results in the
   same data used in the above example, where the RD and PC elements are
   not sufficient to locate a unique address leads to an "invalid"
   result.  This is the case, despite the fact that the LoST server
   typically contains additional location elements which could have
   resulted in a uniquely identifiable location if additional data had
   been supplied in the query.  Since [RFC5222] currently does not have
   a way for this additional location information to be returned in the
   findServiceResponse, this document extends RFC5222 so that it can
   include one or more similarLocation elements within the
   findServiceResponse message representing "similar" civic locations.

   To show this, suppose that a similar address as above is inserted
   within a Lost findService request:

   input address: 6000 15th Ave Seattle, WA.

   Different from the above case, this time we make the assumption that
   the address is deemed "invalid" by the LoST server because there is
   no plain "15th Ave" in the city of Seattle with a house number that
   matches 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 examples of the LoST request and response xml
   message fragments for the above valid and invalid scenarios,
   returning the complete or similar addresses, respectively:















Marshall, et al.        Expires January 13, 2012                [Page 8]


Internet-Draft    Returned Location Extensions to LoST         July 2011


4.  Returned Location Information

   The LoST server knows the data that is available internally, and can
   determine which additional elements can be provided either as part of
   a complete civic location (CCL) or a similar civic location (SCL).
   The inclusion of either CCL or SCL is not triggered by any message
   parameter, but is triggered based on whether the returned location
   information is valid or invalid.  It is not turned on or off, but is
   implementation specific.










































Marshall, et al.        Expires January 13, 2012                [Page 9]


Internet-Draft    Returned Location Extensions to LoST         July 2011


5.  Complete Location returned for Valid response

   Based on the example input request, returned location information is
   provided in a findServiceResponse message when the original input
   address is considered valid, but is missing some additional data that
   the LoST server has.


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


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

            <A3>Seattle</A3>
            <A6>15th</A6>
            <STS>Ave</STS>
            <POD>NW</POD>
            <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>




Marshall, et al.        Expires January 13, 2012               [Page 10]


Internet-Draft    Returned Location Extensions to LoST         July 2011


        </mapping>

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

          <valid>ca:A3 ca:A6 ca:STS ca:POD ca:HNO</valid>
          <invalid></invalid>
          <unchecked></unchecked>

          <rli:completeLocation>  <!-- completed address -->
            <ca:civicAddress>
              <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>98106</ca:PC>
              <ca:PCN>SEATTLE</ca:PCN>
            </ca:civicAddress>

        </rli:completeLocation>

      </locationValidation>

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

        <locationUsed id="587cd3880"/>

      </findServiceResponse>


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















Marshall, et al.        Expires January 13, 2012               [Page 11]


Internet-Draft    Returned Location Extensions to LoST         July 2011


6.  Similar Location returned for Invalid Response

   The following example shows returned location information provided in
   a findServiceResponse message when the original input address is
   considered invalid, because (in this case) of missing data that the
   LoST server needs to provide a unique mapping.


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


      <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, et al.        Expires January 13, 2012               [Page 12]


Internet-Draft    Returned Location Extensions to LoST         July 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>

          <rli:similarLocation>  <!-- similar location info -->
            <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>98106</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>
        </rli:similarLocation>

      </locationValidation>

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

        <locationUsed id="587cd3880"/>

      </findServiceResponse>


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






Marshall, et al.        Expires January 13, 2012               [Page 13]


Internet-Draft    Returned Location Extensions to LoST         July 2011


7.  Relax NG schema

   This section provides the Relax NG schema of LoST extensions in the
   compact form.  The verbose form is included in a later section [TBA].


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

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

     ##
     ##    LoST Extensions define two new elements: completeLocation and
     ##    similarLocation.
     ##
     start =
       completeLocation
       | similarLocation


     ##
     ##    complete Location
     ##
     div {
       completeLocation=
         element completeLocation
     }

     ##
     ##    similar Location
     ##
     div {
       similarLocation=
         element completeLocation
     }


     ##
     ##    Patterns for inclusion of elements from schemas in
     ##    other namespaces.
     ##
     div {

       ##
       ##    Any element not in the LoST Extensions
       ##    namespace.



Marshall, et al.        Expires January 13, 2012               [Page 14]


Internet-Draft    Returned Location Extensions to LoST         July 2011


       ##
       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*
     }



  [Editor's note: above needs refinement]




























Marshall, et al.        Expires January 13, 2012               [Page 15]


Internet-Draft    Returned Location Extensions to LoST         July 2011


8.  Security Considerations

   Whether the input to the LoST server is valid or invalid, the LoST
   server ultimately determines what it considers to be valid.  In the
   case where the input location is valid, the requester still may not
   actually understand where that locaiton is.  For valid location use
   cases, this extension returns more location information than the
   requester may have had which, in turn, may reveal more about the
   location.  While this may be very desirable when, for example,
   supporing an emergency call, it may not be as desirable for other
   services.  The LoST server implementation should consider the risk of
   releasing more detail verses the value in doing so.  Generally, we do
   not believe this is a significant problem as the requester must have
   enough location information to be considered valid, which in most
   cases is enough to uniquely locate the address.  Providing more
   CAtypes generally doesn't actually reveal anything more.



































Marshall, et al.        Expires January 13, 2012               [Page 16]


Internet-Draft    Returned Location Extensions to LoST         July 2011


9.  IANA Considerations


















































Marshall, et al.        Expires January 13, 2012               [Page 17]


Internet-Draft    Returned Location Extensions to LoST         July 2011


10.  Acknowledgements


















































Marshall, et al.        Expires January 13, 2012               [Page 18]


Internet-Draft    Returned Location Extensions to LoST         July 2011


11.  References

11.1.  Normative References

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

11.2.  Informative References

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.







































Marshall, et al.        Expires January 13, 2012               [Page 19]


Internet-Draft    Returned Location Extensions to LoST         July 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


   Brian Rosen
   Neustar
   470 Conrad Dr
   Mars, PA  16046
   US

   Phone:
   Email: br@brianrosen.net
   URI:
















Marshall, et al.        Expires January 13, 2012               [Page 20]