The LoST protcol supports the validation of civic location information as input, by providing a set of validation result status indicators. The current usefulness of the supported xml elements, "valid", "invalid", and "unchecked", is limited, because while they each provide an indication of validity for any one location element as a part of the whole civic address, the mechanism is insufficient in providing either the complete set of civic address elements that the LoST server contains, or of providing alternate suggestions (hints) as to which civic address is intended for use. 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 civic address elements for those valid or invalid cases. This enhancement to the validation feature within LoST is required by systems that rely on accurate location for processing in order to increase the likelihood that the correct and/or complete form of a civic location becomes known in those cases where it is incomplete or just plain wrong. One such use case is that of location based emergency calling. The use of this protocol extension will protocol extension will facilitate the correction of errors, and allow location servers to be more easily provisioned with complete address information. The structure of this document includes terminology, , followed by a discussion of the basic elements involved in location validation. The 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. The following terms are defined in this document: The term Location can be used to refer to either a civic location or a geodetic location. a geographic coordinate set of values that describes a point within a defined geographic datum. For example, a WGS84 referenced lattitude, longitude coordinate pair (2D), or lattitude, longitude, and altitude (3D). Note: geodetic location is defined here for context, but is not used elsewhere within this document. The term civic location applies to a set of one or more civic address elements that are used in conjunction with each other, and in accordance with a known ruleset to to designate a specific place within a region of geography, or a region of geography by itself as defined in . The term Civic Address is used interchangeably with the term Civic Location within this document. The term Civic Address Element is used within this document to apply to an individual CAtype data descriptor, for example, as is described in , , and . A Civic Location that was included in a LoST request and subsequently returned with one or more civic address elements marked as invalid. Note that location information may be submitted in the findRequest that causes the LoST server to return locationInvalid. It is also possible that the location information submitted is so inaccurate that this extension can not be used, and the LoST server may return a notFound. In this document, we use the term Invalid Location only to refer to a case where the LoST server returns one or more elements in the invalid list. A Civic Location that was included in a LoST request and subsequently returned with all civic address elements in the valid or unchecked lists. An expanded civic location that includes other civic address elements in addition to the existing validated civic address elements provided as input to a LoST server. A suggested civic location that is comparatively close to the civic location which was input, but which had one or more invalid civic address elements returned by the LoST server. A set of civic locations returned in a LoST response.

This document describes an extension to LoST to allow additional location information to be returned in a findServiceResponse where the location information in the request is in a civic profile as described in RFC5222 or location in another profile derived from that civic profile, for two different use cases. When a LoST server is asked to validate a civic location, its goal is to take the set of civic address elements provided as the location information in the LoST request, and find a unique location in its database that matches the information in the request. Uniqueness might not require values for all possible elements in the civic address that the database might hold. Further, the input location information might not represent the form of location the users of the LoST service prefer to have. As an example, there are LoST civic address elements that could be used to define a postal location, suitable for delivery of mail as well as a municipal location suitable for responding to an emergency call. While the LoST server might 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 end-user placing an emergency call, if the LoST server could return the preferred form of location (or more properly in this example, the municipal elements in addition to the postal elements), those elements could be stored in a LIS and used in a later emergency call. In addition, this document describes the reuse of the same mechanism, but for a different purpose: to supply similar location information in the case where a LoST server response includes one or more civic address elements marked as invalid, constituting an invalid location response. In this case, the response contains one or more suggested alternative, but valid locations. In a LoST <findServiceResponse> indicating a valid location – i.e. containing a <locationValidation> element with no elements listed as invalid – the <locationValidation> element may use this extension to include additional location information. As an example, the query might contain a HNO (house number), RD (road name) A3 (city), At (state/province) and a few more CAtype elements, but might not contain A2 (county) or PC (Postal Code) CAtypes. The HNO, RD, STS, POD, A3 and A1 civic address elements might be sufficient enough to the LoST server to uniquely locate the address specified in the request and thus be considered valid. Yet, downstream entities might find it helpful to have the additional A2 (county), and PC, (Postal Code), civic address elements that are present within the LoST server, be included as part of a complete location response. Since currently does not have a way for this additional location information to be returned in the findServiceResponse, this document extends the LoST protocol so that it can include a completeLocation element within the findServiceResponse message, allowing for the representation of complete location information. An example showing complete location information supplied: input address: 6000 15th Ave NW Seattle complete location: 6000 15th Ave NW Seattle, WA 98105 US The information provided in the request may be enough to identify a unique location in the LoST server, but that may not be the location intended by the user. The completedLocation information may alert the user to a mismatch between the provided location information and the unique location the server interpreted that information to identify. By contrast, when invalid location is received from the LoST server, with this extension, the same mechanism works as follows: if a LoST server returns a response to a findService request that contains a set of civic address elements with one or more labeled as invalid, the location information in the findServiceResponse is extended to include additional location information that it suspects might be the location desired. In the example cited above, policy at the LoST server might deem a missing A3 element as invalid, even if the location information in the request was sufficient to identify a unique address. In that case, the missing element would be listed in the invalid list, and similarLocation could be returned in the response showing the missing elements including A3, the same as the above example. As another example of the use of similarLocation, consider the results based on a similar data set as used above, where the HNO, RD, STS, A1, and A3 civic address elements are not sufficient to locate a unique address, which leads to an invalid location result. This is the case, despite the fact that the LoST server typically contains additional civic address elements which could have resulted in a uniquely identifiable location if additional data had been supplied with the query. Since currently does not have a way for this additional location information to be returned in the findServiceResponse, this document extends so that the LoST findServiceResponse message can include one or more similarLocation elements within the findServiceResponse message representing similar civic locations. To show this, suppose that a slightly modified address as above is inserted within a Lost findService request: input address: 6000 15th Ave N Seattle, WA. This time we make the assumption that the address is deemed "invalid" by the LoST server because there is no such thing as "15th Ave N" within the LoST server's data for the city of Seattle. However, we also happen to know for this example that 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 extension would allow the LoST server 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 implementing this extension MAY include completeLocation or similarLocation in the findService response. completeLocation and similarLocation contain a list of civic address elements identical to the elements used in the location element with the "civic profile" in or another profile derived from the civic profile. The LoST server MAY include more than one similarLocation elements in the response, but SHOULD NOT return more than a few possible similar locations. If there are too many possible locations, the server MAY return none, or it MAY return the few it considers most likely. The definition of “few” is left to the implementation of the LoST server. The server is unable to know what the intended location information was suppose to be; it is guessing. Therefore the correct location may or may not be one of the similarLocation elements the server provides, and the client cannot assume that any of them are the correct one. Where a LoST server contains additional location information relating to that civic address, the findServiceResponse message MAY return additional location information along with the original validated civic address elements in order to form a complete location based on local implementation policy in the completeLocation element. completeLocation MUST NOT be returned in response messages where any civic address elements occur in the invalid list of the response, or where the set of civic address elements in the request do not identify a unique location. The complete location MUST NOT contain any elements that would be marked as invalid, or cause an error, if a recipient of that location performs a subsequent findService request using the complete location. However, if a subsequent request includes the complete location, the corresponding request MAY include elements in the unchecked list. Clients MAY ignore the location information this extension defines in the response. The information is optional to send, and optional to use. In the case where the location information in the request was valid, this extension does not change the validity. In the case where the location information in the request is invalid, but alternate location information is returned, the original location remains invalid, and the LoST server does not change the mapping response other than optionally including the information defined by this extension. completeLocation and similarLocation use the locationInformation element from including the profile attribute which is useful if the request contains location information in a profile derived from the civic profile.

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"> <ca:country>US</ca:country> <A1>WA</A1> <A3>Seattle</A3> <RD>15th</RD> <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:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO< /valid> <invalid></invalid> <unchecked></unchecked> <rli:completeLocation>  <ca:civicAddress> <ca:country>US</ca:country> <ca:A1>WA</ca:A1> <ca:A2>KING</ca:A2> <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 of the unmatchable POD data (in this example) 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> <RD>15th</RD> <STS>Ave</STS> <POD>N</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:country ca:A1 ca:A3 ca:STS ca:RD</valid> <invalid>ca:POD</invalid> <unchecked>ca:HNO</unchecked> <rli:similarLocation>  <ca:civicAddress>  <ca:country>US</ca:country> <ca:A1>WA</ca:A1> <ca:A2>KING</ca:A2> <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>  <ca:country>US</ca:country> <ca:A1>WA</ca:A1> <ca:A2>KING</ca:A2> <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 [to be supplied in a later version of this draft].

namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" default namespace ns1 = "urn:ietf:params:xml:ns:lost-rli1" namespace local=““ ## ## Extension to LoST to support returned location information ## start = returnedLocation div { returnedLocationResponse = element returnedLocationResponse { completeLocation, similarLocation, extensionPoint } } ## ## completeLocation ## div { completeLocation = element completedlocation { locationInformation }+ } ## ## similarLocation ## div { similarLocation = element similarLocation { 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-RLI namespace. ## notRLI = element * - (ns1:* | local:*) { 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. Even in the case where the input location is valid, the requester still might not actually understand where that location is. For this kind of valid location use case, this described extension would typically return more location information than the requester started with, which might reveal more about the location. While this might be very desirable in some scenarios including, for example, supporting an emergency call, it might not be as desirable for other services. Individual LoST server implementations SHOULD consider the risk of releasing more detail verses the value in doing so. Generally, it is not expected that this would be 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. For invalid locations that are submitted, this extension would allow the LoST response to include location information which is similar to what was input, again resulting in more information provided in the response than was known during input. LoST server implementations SHOULD evaluate the particular use cases where this extension is supported, and weigh the risks around its use. Many similar database services available today via the Internet offer similar features, such as "did you mean", and address completion, so this capability is not introducing any fundamentally new threat.

LoST Returned Location Information Namespace

Namespace for LoST Returned Location Information extension

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

See RFC????.

END ]]>