]> A LoST extension to support return of complete and similar location info TeleCommunication Systems, Inc.
2401 Elliott Avenue 2nd Floor Seattle WA 98121 US +1 206 792 2424 rmarshall@telecomsys.com http://www.telecomsys.com
TeleCommunication Systems, Inc.
2401 Elliott Avenue 2nd Floor Seattle WA 98121 US +1 206 792 2584 jmartin@telecomsys.com http://www.telecomsys.com
Neustar
470 Conrad Dr Mars PA 16046 US br@brianrosen.net
RAI ECRIT Internet-Draft complete similar civic location lost extension 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.
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 and system input errors, and to support the usefulness of location-based systems in general. The structure of this document includes terminology, , 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, , with accompanying rationale, and a brief discussion of the impacts to LoST, and its current schema.
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, 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: The term Address is used interchangeably with the concept of Civic Location. 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. An unmatched result of an individual civic location element as part of a broader set of elements that make up a 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. An expanded civic location that includes additional address elements in addition to the existing validated civic elements provided. A suggested civic location that is comparatively close to the civic location which was input, but which had one or more invalid element. A set of standard civic location elements returned in a LoST response.
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 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 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:
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.
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" 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> <locationUsed id="587cd3880"/> </findServiceResponse> <!-- =============================================== -->
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"> <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> <via source="authoritative.example"/> </path> <locationUsed id="587cd3880"/> </findServiceResponse> <!-- =============================================== -->
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 }+ } ## ## 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* }
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.
LoST Planned Change Namespace

Namespace for LoST Similar Location extension

urn:ietf:params:xml:ns:lost-similarLocation1

See RFC????.

END ]]>
 &rfc2119; &rfc5222;