A LoST extension to support return of complete and similar location info
draft-marshall-ecrit-similar-location-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Roger Marshall , Jeff Martin , Brian Rosen | ||
| Last updated | 2014-02-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-marshall-ecrit-similar-location-03
ECRIT R. Marshall
Internet-Draft J. Martin
Intended status: Standards Track TCS
Expires: August 18, 2014 B. Rosen
Neustar
February 14, 2014
A LoST extension to support return of complete and similar location info
draft-marshall-ecrit-similar-location-03
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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Marshall, et al. Expires August 18, 2014 [Page 1]
Internet-Draft Returned Location Extensions to LoST February 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Returned Location Information . . . . . . . . . . 4
4. Returned Location Information . . . . . . . . . . . . . . . . 6
5. Complete Location returned for Valid response . . . . . . . . 6
6. Similar Location returned for Invalid Response . . . . . . . 8
7. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . 12
9.2. LoST Namespace Registration . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 a complete set of location
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
Marshall, et al. Expires August 18, 2014 [Page 2]
Internet-Draft Returned Location Extensions to LoST February 2014
and system input errors, and to support the usefulness 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.
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 August 18, 2014 [Page 3]
Internet-Draft Returned Location Extensions to LoST February 2014
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.
When a LoST server is asked to validate a location, its goal is to
take the set of elements in the location information in the request,
and find a unique location in its database that matches the
information in the request. Uniqueness may not require values for
all possible elements in the civic address that the database may
hold. Further, the input location information may not represent the
form of location the users of the LoST service prefer to have. As an
example, there are LoST elements that could be used to define a
postal location, suitable for delivery mail as well as a municipal
location suitable for responding to an emergency call. While the
LoST server may be able to determine the location from the postal
elements provided, the emergency services would prefer that the
municipal location be used for any subsequent emergency call. Since
validation is often performed well in advance of an emergency call,
if the LoST server could return the preferred form of location (or
more properly, the municipal elements in addition to the postal
elements), those elements could be stored in a LIS and used in a
subsequent emergence call.
Since a LoST server often contains more data than what is 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, 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
Marshall, et al. Expires August 18, 2014 [Page 4]
Internet-Draft Returned Location Extensions to LoST February 2014
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
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
Marshall, et al. Expires August 18, 2014 [Page 5]
Internet-Draft Returned Location Extensions to LoST February 2014
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:
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.
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>
Marshall, et al. Expires August 18, 2014 [Page 6]
Internet-Draft Returned Location Extensions to LoST February 2014
<!-- =============================================== -->
<findServiceResponse >
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<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>
<locationValidation
<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>
Marshall, et al. Expires August 18, 2014 [Page 7]
Internet-Draft Returned Location Extensions to LoST February 2014
<locationUsed id="587cd3880"/>
</findServiceResponse>
<!-- =============================================== -->
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:xml: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"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
Marshall, et al. Expires August 18, 2014 [Page 8]
Internet-Draft Returned Location Extensions to LoST February 2014
<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>
<locationValidation
<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>
Marshall, et al. Expires August 18, 2014 [Page 9]
Internet-Draft Returned Location Extensions to LoST February 2014
<via source="authoritative.example"/>
</path>
<locationUsed id="587cd3880"/>
</findServiceResponse>
<!-- =============================================== -->
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-similarLocation1"
##
## Extension to LoST to support returned location information
##
start =
returnedLocation
div {
returnedLocationResponse =
element returnedLocationResponse {
completeLocation, similarLocation, extensionPoint
}
}
##
## completeLocation
##
div {
completeLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
Marshall, et al. Expires August 18, 2014 [Page 10]
Internet-Draft Returned Location Extensions to LoST February 2014
## similarLocation
##
div {
similarLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLost = 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 = notRLI*
}
Marshall, et al. Expires August 18, 2014 [Page 11]
Internet-Draft Returned Location Extensions to LoST February 2014
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 location 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,
supporting 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.
9. IANA Considerations
9.1. Relax NG Schema Registration
URI: urn:ietf:params:xml:schema:lost-similarLocation1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net).
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 7. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost-similarLocation1
and its last line is
}
9.2. LoST Namespace Registration
Marshall, et al. Expires August 18, 2014 [Page 12]
Internet-Draft Returned Location Extensions to LoST February 2014
URI: urn:ietf:params:xml:ns:lost-similarLocation1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net).
XML:
BEGIN
<?xml version="2.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 Planned Change Namespace</title>
</head>
<body>
<h1>Namespace for LoST Similar Location extension</h1>
<h2>urn:ietf:params:xml:ns:lost-similarLocation1</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
RFC????</a>.</p>
</body>
</html>
END
10. Acknowledgements
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.
Authors' Addresses
Marshall, et al. Expires August 18, 2014 [Page 13]
Internet-Draft Returned Location Extensions to LoST February 2014
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
Email: br@brianrosen.net
Marshall, et al. Expires August 18, 2014 [Page 14]