One document matched: draft-thomson-geopriv-http-geolocation-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902">
  <front>
    <title abbrev="HTTP Geolocation">
      HTTP Geolocation
    </title>

    <author initials="M" surname="Thomson" fullname="Martin Thomson">
      <organization>Andrew Corporation</organization>
      <address>
        <postal>
          <street>Andrew Building (39)</street>
          <street>Wollongong University Campus</street>
          <street>Northfields Avenue</street>
          <city>Wollongong</city>
          <region>NSW</region>
          <code>2522</code>
          <country>AU</country>
        </postal>
        <phone>+61 2 4221 2915</phone>
        <email>martin.thomson@andrew.com</email>
      </address>
    </author>

    <author initials="F" surname="Ribeiro" fullname="Fernando Ribeiro">
      <organization></organization>
      <address>
        <postal>
          <street></street>
          <code></code>
          <city></city>
          <country>BR</country>
        </postal>
        <email>webmaster@fernandoribeiro.eti.br</email>
      </address>
    </author>

    <author initials="R." surname="Barnes" fullname="Richard Barnes">
      <organization>BBN Technologies</organization>
      <address>
        <postal>
          <street>9861 Broken Land Pkwy, Suite 400</street>
          <city>Columbia, MD</city>
          <code>21046</code>
          <country>USA</country>
        </postal>
        <phone>+1 410 290 6169</phone>
        <email>rbarnes@bbn.com</email>
      </address>
    </author>

    <date month="March" year="2011"/>
    <area>APP</area>
    <workgroup>GEOPRIV</workgroup>
    <keyword>HTTP</keyword>
    <keyword>Geolocation</keyword>
    <keyword>Location</keyword>
    <keyword>PIDF-LO</keyword>
    <keyword></keyword>

    <abstract>
      <t>A Geolocation header is defined for HTTP.  The Geolocation header provides a reference to location information in an HTTP request.  A server can use this information in processing the request.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes a header for <xref target="RFC2616">Hypertext Transfer Protocol (HTTP)</xref> that includes a reference location information.
      </t>

      <t>The <spanx style="verb">Geolocation</spanx> request header includes a URI to a resource that includes location information.  A server can choose to use this information in serving the request.  How this affects the response is up to the server, but this could be used to select content that is more appropriate for a recipient at the given location.</t>

    </section>

    <section title="Terminology">
      <t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, <xref target="RFC2119">RFC 2119</xref> and indicate requirement levels for compliant implementations.
      </t>

      <t>Some terminology from <xref target="I-D.ietf-geopriv-arch"/> is used.</t>
    </section>

    <section anchor="request-timeout" title="Geolocation Header">
      <t>The <spanx style="verb">Geolocation</spanx> header is a end-to-end request header that includes a reference to location information.  This reference is an <xref target="RFC3986">absolute URI</xref> that identifies a resource that contains location information.
      </t>

      <t>The following <xref target="RFC5234">ABNF</xref> defines the syntax of the Geolocation header.  This ABNF uses the modified syntax and existing rules for HTTP from <xref target="I-D.ietf-httpbis-p1-messaging"/>.</t>

      <figure>
        <artwork type="abnf"><![CDATA[
Geolocation-Header = "Geolocation:" OWS "<" absolute-URI ">"
                     *geoloc-param
geoloc-param       =  OWS ";" OWS token [ "=" word ]
        ]]></artwork>
      </figure>

      <t>The value of location information can be carried in the body of a request using a <spanx style="verb">cid:</spanx> URI <xref target="RFC2392"/>.  The <spanx style="verb">geo:</spanx> URI <xref target="RFC5870"/>provides another means of including location information directly.
      </t>

      <t>Location information that is included by reference to an independent resource means that the server has some control over how location information is acquired.  Depending on the needs of the server, it may need to follow this reference before responding to the request.
      </t>

      <t>A location that is provided by reference to a constantly updating resource could permit a server to request information that better suits their end by a variety of methods.  Content negotiation, <xref target="I-D.ietf-geopriv-deref-protocol">HTTP-Enabled Location Delivery</xref> and <xref target="I-D.ietf-geopriv-loc-filters">location filtering</xref> could be used, depending on the type and capabilities of the identified resource.  Providing location by reference allows a server to request location information some time after receiving the request, enabling applications that operate outside the time of the client-server interaction.  This has potential privacy implications, see <xref target="privacy"/>.
      </t>

      <t>Servers that implement support for the Geolocation header MUST support <spanx style="verb">cid:</spanx>, <spanx style="verb">https:</spanx> and <spanx style="verb">http:</spanx> URIs.  Servers MUST support location information in the form of a <xref target="RFC4119">Presence Information Data Format - Location Object (PIDF-LO)</xref>.
      </t>

      <t>A client SHOULD NOT include multiple Geolocation headers in the same request.  Though it is permitted, a server that doesn't have additional information about each URI might find it difficult to select a single location or reconcile different locations.  <xref target="I-D.ietf-sipcore-location-conveyance"/> provides a discussion on the consequences of including multiple location values.
      </t>

       <t>Resources that provide different representations based on the value of the Geolocation header typically need a Vary header containing <spanx style="verb">Geolocation</spanx> if they can be cached.</t>
     </section>

     <section title="427 (Bad Geolocation) Status Code">
       <t>A status code of 427 indicates that the request contained missing, badly formed, unsupported or inaccessible location information.</t>

       <t>This indicates that a request might be successful if it contained different location information.  The client might:
       <list style="symbols">
         <t>include a Geolocation header (after gaining permission), if one was absent</t>
         <t>include a location value directly, if a location reference was provided</t>
         <t>include a different URI type, if alternatives are available</t>
         <t>modify any authorization rules on the identified resource to permit the server access</t>
       </list>
       </t>

       <t>A representation included in the response SHOULD provide what guidance the server can provide the client in providing a request that will succeed.
       </t>
     </section>

     <section title="Examples">
       <figure>
         <preamble>In the following example, location is included by value.  The Geolocation header references a PIDF-LO document in the body of the request.
         </preamble>
       <artwork><![CDATA[
GET /resource HTTP/1.1
Host: example.com:8443
Geolocation: <cid:rf*c36n89@r.213562>
Content-ID: <rf*c36n89@r.213562>
Content-Length: TBD
Content-Type: application/pidf+xml

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:gs="http://www.opengis.net/pidflo/1.0"
          entity="pres:circle@example.com">
  <tuple id="circle">
    <status>
      <gp:geopriv>
        <gp:location-info>
          <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:pos>42.5463 -73.2512</gml:pos>
            <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
              850.24
            </gs:radius>
          </gs:Circle>
        </gp:location-info>
        <gp:usage-rules/>
        <gp:method>OTDOA</gp:method>
      </gp:geopriv>
    </status>
  </tuple>
</presence>
]]></artwork></figure>

       <figure>
         <preamble>In the following example, location is included by reference to an HTTP resource.
         </preamble>
       <artwork><![CDATA[
GET /resource HTTP/1.1
Host: example.com:8443
Geolocation: <https://lis.example.net/location/scey89pse>

]]></artwork></figure>

       <figure>
         <preamble>In the following example, an error response indicates that the Geolocation was not accessible by the server.
         </preamble>
       <artwork><![CDATA[
HTTP/1.1 427 Bad Geolocation
Host: example.com:8443
Content-Type: text/plain;charset=utf-8
Content-Length: 95

<https://lis.example.net/location/scey89pse> was not accessible.
HTTP Error: 403 Forbidden
]]></artwork></figure>
    </section>

    <section anchor="privacy" title="Privacy Considerations">
      <t>Location information is highly privacy-sensitive.  A discussion of the privacy considerations as they relate to location information in general, and a terminology framework can be found in <xref target="I-D.ietf-geopriv-arch"/>.  Most importantly, a client MUST NOT send location information without the permission of a Rule Maker.
      </t>

      <t><xref target="I-D.ietf-geopriv-arch"/> defines rules for the server that are included in the <xref target="RFC4119">Location Object</xref>.  A conforming server MUST respect the rules regarding location retention and retransmission in PIDF-LO.
      </t>

      <t>Confidentiality protection, as provided by <xref target="RFC2818">HTTP over TLS</xref> MUST be used to protect location information, unless other forms of protection are provided, or a Rule Maker has provided permission for information to be universally distributed.  This applies whether the request contains location information by value or by reference; the guidance in <xref target="RFC5808"/> recommends confidentiality protection for some URIs that reference location.</t>

      <t>Location information that is included by reference to a resource allows the server to retrieve location information outside of the context of the request.  An access control policy on the referenced resource may be used to control access.</t>

      <t>The privacy considerations for this document are similar to those for <xref target="I-D.ietf-sipcore-location-conveyance">SIP location conveyance</xref>, with one major exclusion.  The intermediary architecture for HTTP doesn't support routing in the same way that SIP does and routing based on location information is not possible in the same manner.  For this reason, the privacy concerns relating to routing and the related <spanx style="verb">Routing-Allowed</spanx> header are not relevant to HTTP.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>In addition to the privacy considerations, <xref target="RFC2818">HTTP over TLS</xref> provides integrity protection for location information on a hop-by-hop basis.
      </t>

      <t>Servers that support Geolocation headers need to be aware of the potential attacks that accepting URIs provided by clients could enable.  The security considerations of <xref target="RFC3986"/> contains guidance on using URIs.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>[[Note to IANA/RFC Editor: Please replace instances of RFCXXXX with the number of the published RFC and remove this note.]]
      </t>
      <section title="Geolocation Header Registration">
        <t>This section registers the <spanx style="verb">Geolocation</spanx> HTTP header in the "Permanent Message Header Fields" registry established by <xref target="RFC3864"/>.
          <list style="hanging">
            <t hangText="Header field:">Geolocation</t>
            <t hangText="Applicable protocol:">HTTP</t>
            <t hangText="Status:">standard</t>
            <t hangText="Author/change controller:">Internet Engineering Task Force, IETF (iesg@ietf.org)</t>
            <t hangText="Specification document(s):">RFCXXXX (this document)</t>
          </list>
        </t>
      </section>

      <section title="427 (Bad Geolocation) Status Code Registration">
        <t>This section registers the <spanx style="verb">Bad Geolocation</spanx> HTTP status code in the "Hypertext Transfer Protocol (HTTP) Status Code Registry" registry established by <xref target="I-D.ietf-httpbis-p2-semantics"/>.
          <list style="hanging">
            <t hangText="Status Code Value:">427</t>
            <t hangText="Description:">Bad Geolocation</t>
            <t hangText="Reference:">RFCXXXX (this document)</t>
          </list>
        </t>
      </section>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2392"?>
      <?rfc include="reference.RFC.2616"?>
      <?rfc include="reference.RFC.2818"?>
      <?rfc include="reference.RFC.3864"?>
      <?rfc include="reference.RFC.3986"?>
      <?rfc include="reference.RFC.4119"?>
      <?rfc include="reference.RFC.5234"?>
      <?rfc include="reference.I-D.ietf-sipcore-location-conveyance"?>
      <?rfc include="reference.I-D.ietf-httpbis-p1-messaging"?>
      <?rfc include="reference.I-D.ietf-httpbis-p2-semantics"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.5808"?>
      <?rfc include="reference.RFC.5870"?>
      <?rfc include="reference.I-D.ietf-geopriv-arch"?>
      <?rfc include="reference.I-D.ietf-geopriv-deref-protocol"?>
      <?rfc include="reference.I-D.ietf-geopriv-loc-filters"?>
    </references>
  </back>

</rfc>