One document matched: draft-thomson-geopriv-held-get-01.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 RFC2616   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.ietf-geopriv-lis-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lis-discovery.xml">
<!ENTITY I-D.winterbottom-geopriv-deref-protocol PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-deref-protocol.xml">
<!ENTITY I-D.ietf-geopriv-lbyr-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml">
]>


<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" ipr="trust200902">
  <front>
    <title abbrev="HELD GET">Using HTTP GET with HTTP-Enabled Location Delivery (HELD)</title>
       <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Andrew Corporation</organization>
      <address>
        <postal>
          <street>PO Box U40</street>
          <city>University of Wollongong</city>
          <region>NSW</region>
          <code>2500</code>
          <country>AU</country>
        </postal>
        <phone>+61 242 212915</phone>
        <email>martin.thomson@andrew.com</email>
        <uri>http://www.andrew.com/products/geometrix</uri>
      </address>
    </author>

    <date month="October" year="2009"/>
    <area>Real-Time Applications and Infrastructure</area>
    <workgroup>Geopriv</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>HELD</keyword>
    <keyword>GET</keyword>

    <abstract>
      <t>This document describes how an HTTP GET request to an HTTP-Enabled Location Delivery (HELD) resource is handled by the server responsible for that resource.  This ensures that requests generated by user agents that are unaware of the special status of a URI do not result in unhelpful responses and enables the use of HTTP GET for location configuration and dereference.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The <xref target="I-D.ietf-geopriv-http-location-delivery">HTTP-Enabled Location Delivery (HELD) protocol</xref> prohibits the use of the HTTP GET method.  It does this because a HELD request is not always <xref target="RFC2616">safe and idempotent</xref>, an attribute necessary for use of GET.
      </t>

      <t>The behaviour that is expected when a client makes an HTTP GET request to the a HELD URI is therefore undefined.  GET is the method assumed by generic user agents, therefore unless context identifies an <spanx style="verb">https:</spanx> URI as a HELD URI, such a user agent might simply send an HTTP GET.
      </t>

      <t>Rather than providing an HTTP 405 (Method Not Allowed) response indicating that POST is the only permitted method, this document specifies that a LIS provides a HELD location response if it receives an HTTP GET request.
      </t>
    </section>

    <section anchor="terminology" title="Terminology">

      <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 anchor="lo" title="HTTP GET Behaviour">
      <t>A HELD URI is an <spanx style="verb">https:</spanx> or <spanx style="verb">http:</spanx> URI that is either the product of <xref target="I-D.ietf-geopriv-lis-discovery">LIS discovery</xref> or a location URI generated by a LIS.
      </t>

      <figure>
        <preamble>An HTTP GET request to a HELD URI produces a HELD response as if the following HELD request had been sent using HTTP POST:
        </preamble>
        <artwork><![CDATA[
  <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
    <locationType exact="false">
      geodetic civic
    </locationType>
  </locationRequest>
]]></artwork>
      </figure>


      <t>If the URI is a location URI, the limited profile of HELD described in <xref target="I-D.winterbottom-geopriv-deref-protocol"/> is applied.  In particular, a location URI MUST NOT be provided in response to a location dereferencing request.
      </t>

      <t>HTTP GET requests must be safe and idempotent - that is, there are no side-effects of making the request and repeating the request does not change the result.  If the response provides a location object, this does not pose a problem.  Changes in the location information do not occur as a result of requests, they are a result of a change in the value of the resource (the resource being the location of the Target).
      </t>

      <t>To ensure that these requests are idempotent, a LIS MUST NOT generate a location URI as a result of serving this request.  However, if a location URI already exists, it MAY be provided.  To achieve this, a location URI might be pre-allocated based on Target identity.  This approach only works as long as the location URI operates on the "authorization by possession" authorization model (<xref target="I-D.ietf-geopriv-lbyr-requirements"/>).
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The security considerations of <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> apply.  This document introduces no further security considerations.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document has no IANA actions.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC2616;
      &I-D.ietf-geopriv-http-location-delivery;
    </references>

    <references title="Informative References">
      &I-D.ietf-geopriv-lis-discovery;
      &I-D.winterbottom-geopriv-deref-protocol;
      &I-D.ietf-geopriv-lbyr-requirements;
    </references>
  </back>
</rfc>