Skip to main content

A LoST extension to return complete and similar location info
draft-ietf-ecrit-similar-location-02

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 "Active".
Authors Roger Marshall , Jeff Martin , Brian Rosen
Last updated 2016-03-21
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Aug 2017
Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ecrit-similar-location-02
ECRIT                                                        R. Marshall
Internet-Draft                                                 J. Martin
Intended status: Standards Track                                     TCS
Expires: September 22, 2016                                     B. Rosen
                                                                 Neustar
                                                          March 21, 2016

     A LoST extension to return complete and similar location info
                  draft-ietf-ecrit-similar-location-02

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
   valid or invalid civic address elements are 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 address
   element set for a valid location response, and one or more suggested
   sets of similar location information for invalid LoST responses.
   These two types of civic addresses are referred to as either
   "complete location" or "similar location", and are included as a
   compilation of CAtype xml elements within the existing LoST
   findServiceResponse 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 September 22, 2016.

Marshall, et al.       Expires September 22, 2016               [Page 1]
Internet-Draft    Returned Location Extensions to LoST        March 2016

Copyright Notice

   Copyright (c) 2016 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of Returned Location Information . . . . . . . . . .   4
   4.  Returned Location Information . . . . . . . . . . . . . . . .   7
     4.1.  Complete Location returned for Valid Location response  .   7
     4.2.  Similar Location returned for Invalid Location response .   9
   5.  Relax NG schema . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Relax NG Schema Registration  . . . . . . . . . . . . . .  14
     7.2.  LoST Namespace Registration . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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 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

Marshall, et al.       Expires September 22, 2016               [Page 2]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   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, Section 2,
   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, 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].

   The following terms are defined in this document:

   Location:  The term Location can be used to refer to either a civic
      location or a geodetic location.

   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.

   Civic Location:  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 [RFC5139].

   Civic Address:  The term Civic Address is used interchangeably with
      the term Civic Location within this document.

Marshall, et al.       Expires September 22, 2016               [Page 3]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   Civic Address Element:  The term Civic Address Element is used within
      this document to apply to an individual CAtype data descriptor,
      for example, as is described in [RFC4776], [RFC5774], and
      [RFC6848].

   Invalid:  The status result of the unsuccessful attempt to match an
      individual input data as part of a larger set of data that has
      already been successfully matched and as shown by the [RFC5222]
      defined xml named element.

   Valid:  The status result of the successful attempt to match an
      individual input data as part of a larger set of data that has
      already also been successfully matched and shown by the [RFC5222]
      defined xml named element.

   Invalid Location:  A Civic Location that was included in a LoST
      request and subsequently returned with one or more civic address
      elements marked as invalid.

   Valid Location:  A Civic Location that was included in a LoST request
      and subsequently returned with all civic address elements marked
      as valid.

   Complete Location:  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.

   Similar Location:  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.

   Returned Location Information:  A set of standard civic address
      elements returned in a LoST response.

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 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

Marshall, et al.       Expires September 22, 2016               [Page 4]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   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.

   Since a LoST server often contains more data than what is included
   within a findService request, it is expected that this additional
   location information, if present, SHOULD only be returned within
   response messages that contain only valid civic address elements in
   the corresponding request, and where the set of valid civic address
   elements in the request identify a unique location.  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 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.

   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.

   In a valid location response, a LoST server returns a response to a
   findService request that contains a set of civic address elements
   marked valid.  The location information in the findServiceResponse
   message MAY be extended to include additional location information
   specific for that location.  As an example, the query might contain a
   HNO (house number), RD (road name) and A3 (city) and a few more
   CAtype elements, but might not contain A1 (state) or PC (Postal Code)

Marshall, et al.       Expires September 22, 2016               [Page 5]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   CAtypes.  The HNO, RD, STS, POD, and A3 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
   country, A1 (state), and PC, (Postal Code), civic address elements
   that are present within the LoST server, be included as part of a
   complete location response.  Since [RFC5222] 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

   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 [RFC5222] currently does not have a way for
   this additional location information to be returned in the
   findServiceResponse, this document extends [RFC5222] so that the LoST
   findServiceResponse message can include one or more similarLocation
   elements within the findServiceResponse message representing similar
   civic locations.

Marshall, et al.       Expires September 22, 2016               [Page 6]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   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.

4.  Returned Location Information

   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".

   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.

4.1.  Complete Location returned for Valid Location response

   Based on the example input request, returned location information is
   provided in a findServiceResponse message when the original input

Marshall, et al.       Expires September 22, 2016               [Page 7]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   address is considered valid, but is missing some additional data that
   the LoST server has.

      <!-- =====Request=================================== -->

      <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">

            <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>

      <!-- =====Response================================== -->

      <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>

Marshall, et al.       Expires September 22, 2016               [Page 8]
Internet-Draft    Returned Location Extensions to LoST        March 2016

        </mapping>

        <locationValidation

          <valid>ca:A3 ca:RD 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>

      <!-- =============================================== -->

4.2.  Similar Location returned for Invalid Location response

   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.

   <!-- =====Request=================================== -->

Marshall, et al.       Expires September 22, 2016               [Page 9]
Internet-Draft    Returned Location Extensions to LoST        March 2016

      <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>

      <!-- =====Response=================================== -->

      <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>

Marshall, et al.       Expires September 22, 2016              [Page 10]
Internet-Draft    Returned Location Extensions to LoST        March 2016

          <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>

      <!-- =============================================== -->

5.  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 [to be
   supplied in a later version of this draft].

Marshall, et al.       Expires September 22, 2016              [Page 11]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
   default namespace ns1 = "urn:ietf:params:xml:ns:lost-rli1"

   ##
   ##       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

Marshall, et al.       Expires September 22, 2016              [Page 12]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   ##       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*
   }

6.  Security Considerations

   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

Marshall, et al.       Expires September 22, 2016              [Page 13]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   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.

7.  IANA Considerations

7.1.  Relax NG Schema Registration

      URI:  urn:ietf:params:xml:schema:lost-rli1

      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-rli1

      and its last line is

      }

7.2.  LoST Namespace Registration

Marshall, et al.       Expires September 22, 2016              [Page 14]
Internet-Draft    Returned Location Extensions to LoST        March 2016

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

      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 Returned Location Information extension</h1>
     <h2>urn:ietf:params:xml:ns:lost-rli1</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
      RFC????</a>.</p>
   </body>
   </html>
   END

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
              <http://www.rfc-editor.org/info/rfc5222>.

8.2.  Informative References

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776,
              DOI 10.17487/RFC4776, November 2006,
              <http://www.rfc-editor.org/info/rfc4776>.

Marshall, et al.       Expires September 22, 2016              [Page 15]
Internet-Draft    Returned Location Extensions to LoST        March 2016

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
              February 2008, <http://www.rfc-editor.org/info/rfc5139>.

   [RFC5774]  Wolf, K. and A. Mayrhofer, "Considerations for Civic
              Addresses in the Presence Information Data Format Location
              Object (PIDF-LO): Guidelines and IANA Registry
              Definition", BCP 154, RFC 5774, DOI 10.17487/RFC5774,
              March 2010, <http://www.rfc-editor.org/info/rfc5774>.

   [RFC6848]  Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
              R. George, "Specifying Civic Address Extensions in the
              Presence Information Data Format Location Object (PIDF-
              LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013,
              <http://www.rfc-editor.org/info/rfc6848>.

Authors' Addresses

   Roger Marshall
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   Email: rmarshall@telecomsys.com
   URI:   http://www.telecomsys.com

   Jeff Martin
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   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 September 22, 2016              [Page 16]