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]