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. US WA Seattle 15th Ave 6000 urn:service:sos Seattle 911 urn:service:sos sip:seattle-911@example.com 911 Marshall & Martin Expires August 5, 2011 [Page 8] Internet-Draft Similar Location Extension to LoST February 2011 ca:country ca:A1 ca:A3 ca:A6 ca:HNO US WA SEATTLE 15TH AVE NW 6000 98107 SEATTLE US WA SEATTLE 15TH AVE NE 6000 98105 SEATTLE 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 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 with a locationValidation that contains an invalid, it is recommended that the LoST server try to include one or more in the , 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]