One document matched: draft-rosen-ecrit-lost-return-li-00.txt

ECRIT                                                           B. Rosen
Internet-Draft                                                   Neustar
Intended status: Standards Track                          March 29, 2011
Expires: September 30, 2011


 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.

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



Rosen                  Expires September 30, 2011               [Page 1]

Internet-Draft               LoST Return LI                   March 2011


   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 . . . . . . . . . . . . . . . 3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  responseLocation  . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  XML Schema Registration . . . . . . . . . . . . . . . . . . 5
     6.2.  LoST Extension to Return LI Relax NG Schema
           Registration  . . . . . . . . . . . . . . . . . . . . . . . 6
     6.3.  LoST Extension to return LI Namespace Registration  . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7


































Rosen                  Expires September 30, 2011               [Page 2]

Internet-Draft               LoST Return LI                   March 2011


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



Rosen                  Expires September 30, 2011               [Page 3]

Internet-Draft               LoST Return LI                   March 2011


      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



Rosen                  Expires September 30, 2011               [Page 4]

Internet-Draft               LoST Return LI                   March 2011


        ##    (elements from other namespaces)
        ##    can be added.
        ##
        extensionPoint = notLostRP*
      }

                         Figure 1: Relax NG Schema

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.













Rosen                  Expires September 30, 2011               [Page 5]

Internet-Draft               LoST Return LI                   March 2011


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




Rosen                  Expires September 30, 2011               [Page 6]

Internet-Draft               LoST Return LI                   March 2011


7.  Acknowledgements

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

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

Author's Address

   Brian Rosen
   Neustar
   470 Conrad Dr
   Mars, PA  16046
   US

   EMail: br@brianrosen.net

























Rosen                  Expires September 30, 2011               [Page 7]