Returning a Location Information in a Location to Service Translation query
draft-rosen-ecrit-lost-return-li-00

Abstract

This document defines an extension to LoST (RFC5222) to permit a location information to be returned in a findservice response. When the validation is requested in the findservice request, the location information supplied in the request may have enough valid address components (CAtypes) to be considered valid, but the LoST server may wish to return address components CAtypes not found in the query.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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 30, 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.

Table of Contents

• 1. Conventions used in this document
• 2. Overview
• 3. responseLocation
• 4. Relax NG Schema
• 5. Security Considerations
• 6. IANA Considerations
• 6.1. XML Schema Registration
• 6.2. LoST Extension to Return LI Relax NG Schema Registration
• 6.3. LoST Extension to return LI Namespace Registration
• 7. Acknowledgements
• 8. References
• Author's Address

1. Conventions used in this document

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 [RFC2119].

2. Overview

This document describes an extension to LoST [RFC5222], to allow location information to be returned in a <findServiceResponse>. When requesting validation, the location information in the <findService> request may contain enough CAtypes to be considered valid. The LoST server may have all of the address components for the location. As an example, the query may contain a PC, postal code, but may not contain A1, A2 or A3 CAtypes. The street name and PC may be sufficient to locate the address specified in the request and thus be considered. It may be helpful to downstream entities to have the A1-A3 components, and the LoST server could supply them. However, [RFC5222] does not have a way for location information to be returned in the <findServiceResponse>. This document adds the possibility to include a <location> element to the <findServiceResponse> message.

3. responseLocation

This document defines a new element <responseLocation> which MAY be included in a <findServiceResponse> when validation is requested. It MUST NOT be used in any other request or response. The Location Information in the response MUST contain all of the location information in the request and MAY contain any additional CAtypes that refer to the same location specified in the request.

4. Relax NG Schema

This section provides the Relax NG schema for an extension to include the <location> in the <findServiceResponse> in the compact form. The verbose form is included in Appendix A.

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

   ##
   ##    Extensions to the Location-to-Service Translation (LoST)
   ##    Protocol

   ##
   ##    LoST Extensions to optionally return a <location> in
   ##       <findServiceResponse>
   ##
   start =
     responseLocation


   ##
   ##    findServiceResponse
   ##
   div {
     findServiceResponse =
       extensionPoint+,
       attribute profile { xsd:NMTOKEN }?
   }

##
##       Location in Responses
##
div {
  responseLocation =
    element location {
      attribute id { xsd:token },
      locationInformation
    }+
}


   ##
   ##    Patterns for inclusion of elements from schemas in
   ##    other namespaces.
   ##
   div {

     ##
     ##    Any element not in the LoST Extensions
     ##    namespace.
     ##
     notLostRP = 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 = notLostRP*
   }
        

5. Security Considerations

Although the input to the LoST request may be valid, however the LoST server determines what valid is, the requester may not actually understand where that is. This extension returns more location information that the requester may not have had which may reveal more about the location. While this may be very desirable for, e.g. 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.

6. IANA Considerations

6.1. XML Schema Registration

This section registers an XML schema as per the procedures in [RFC3688].

   URI:  urn:ietf:params:xml:schema:lostRLI

   Registrant Contact:  IETF, ECRIT working group (ecrit@ietf.org),
      Brian Rosen (br@brianrosen.net).

      The XML for this schema can be found as the entirety of Section 7
      of this document.

6.2. LoST Extension to Return LI Relax NG Schema Registration

   URI: urn:ietf:params:xml:schema:lostRLI

   Registrant Contact: Brian Rosen (br@brianrosen.net)

   Relax NG Schema: The Relax NG schema to be registered is contained in
   Section 4.  Its first line is

   default namespace ns1 = "urn:ietf:params:xml:ns:lostRLI"

   and its last line is

   }

6.3. LoST Extension to return LI Namespace Registration

   URI: urn:ietf:params:xml:ns:lost1:ext

   Registrant Contact: Brian Rosen (br@brianrosen.net)

   XML:

   BEGIN
   <?xml version="1.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 Extension to Return LI Namespace</title>
   </head>
   <body>
     <h1>Namespace for LoST Extension to return LI</h1>
     <h2>urn:ietf:params:xml:ns:lostRLI</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
      RFCXXXX</a>.</p>
   </body>
   </html>
   END
  <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX 
       with the number of the published
       document and remove this note.]] -->
       END
    

7. Acknowledgements

This work arose from discussions held within the NENA Long Term Development work group.

8. References

Author's Address