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

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">


]>

<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>

<rfc category="std" ipr="trust200902" docName="draft-rosen-ecrit-lost-return-li-00">
  <front>
    <title abbrev="LoST Return LI">
      Returning a Location Information in a Location to Service Translation query
    </title>

   <author initials="B." surname="Rosen" fullname="Brian Rosen">
      <organization>Neustar</organization>
      <address>
        <postal>
          <street>470 Conrad Dr</street>
          <city>Mars</city>
          <region>PA</region>
          <code>16046</code>
          <country>US</country>
        </postal>
        <email>br@brianrosen.net</email>
      </address>
    </author>


    <date year="2011"/>
    <area>RAI</area>
    <workgroup>ECRIT</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>LoST</keyword>
    <keyword>PIDF</keyword>

    <abstract>
      <t>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.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="conventions" title="Conventions used in this document">
      <t>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 <xref target="RFC2119"/>.
      </t>

    </section>

    <section title="Overview">
      <t>This document describes an extension to LoST <xref target="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, <xref target="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. </t>
</section>
<section title="responseLocation">
<t>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.</t>
</section><section title="Relax NG Schema">
<t>   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.</t>
      <figure anchor="Schema" title="Relax NG Schema">
        <artwork><![CDATA[
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*
   }
        ]]></artwork>
      </figure>

    </section>
    <section anchor="security" title="Security Considerations">
      <t>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.</t>

    </section>

    <section anchor="iana" title="IANA Considerations">

<section title="XML Schema Registration">
<t>
   This section registers an XML schema as per the procedures in
   <xref target="RFC3688"/>.</t>
<figure><artwork><![CDATA[

   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.
]]></artwork></figure></section>
 <section title="LoST Extension to Return LI Relax NG Schema Registration">
<figure><artwork><![CDATA[

   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

   }
]]></artwork></figure></section>

<section title="LoST Extension to return LI Namespace Registration">
<figure><artwork><![CDATA[

   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
    
]]></artwork></figure></section>
   </section>
    <section title="Acknowledgements">
      <t>This work arose from discussions held within the NENA Long Term Development work group.
      </t>
    </section>
  </middle>

  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC5222;
      &RFC3688;
    </references>


  </back>
</rfc>