One document matched: draft-hammer-hostmeta-00.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<rfc category="info" ipr="trust200902" docName="draft-hammer-hostmeta-00">

  <?rfc strict="yes" ?>
  <?rfc toc="yes" ?>
  <?rfc tocdepth="2" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes" ?>
  <?rfc compact="yes" ?>
  <?rfc subcompact="no" ?>

  <front>
    
    <title>Host-Meta: Web Host Metadata</title>

    <author initials="E" surname="Hammer-Lahav" fullname="Eran Hammer-Lahav">
      <organization>
        Yahoo!
      </organization>
      <address>
        <email>eran@hueniverse.com</email>
        <uri>http://hueniverse.com</uri>
      </address>
    </author>

    <date year="2009"/>

    <abstract>
      <t>
        This memo describes a method for locating host-specific metadata for the Web using a
        "well-known location" XRD document.
      </t>
    </abstract>
  
  </front>

  <middle>
    <section title="Introduction">
      <t>
        [[ The host-meta document was originally proposed in <xref target="I-D.nottingham-site-meta" />.
        That draft was changed from a single document-based list of metadata links to a
        registry of well-known locations documents under a fixed path prefix. This memo redefines
        the purpose and syntax of the host-meta document. ]]
      </t>
      <t>
        It is increasingly common for Web-based protocols to require the discovery of policy or
        metadata before making a request. For example, the Robots Exclusion Protocol specifies a
        way for automated processes to obtain permission to access resources; likewise, the
        Platform for Privacy Preferences <xref target="W3C.REC-P3P-20020416"/> tells user-agents
        how to discover privacy policy beforehand.
      </t>
      <t>
        While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV's
        PROPFIND <xref target="RFC4918"/>), the overhead associated with them often precludes their
        use in these scenarios. In addition, there is no URI or resource available to associate
        host metadata with which lead some protocols use the root HTTP resource for this purpose.
      </t>
      <t>
        When this happens, it is common to designate a "well-known location" for such metadata, so
        that it can be easily retrieved. <xref target="I-D.nottingham-site-meta" /> defines a
        registry for such "well-known locations" which addresses the issues associated with their
        use (i.e. name collisions and violating the namespace authority of the domain owner).
      </t>
      <t>
        Web protocols have a wide range of metadata requirements. However, it is common for Web
        protocols to define metadata that is concise, does not require complex or custom syntax,
        and does not justifies the registration and retrival of multiple protocol-specific
        "well-known locations". This memo defines a simple, general-purpose metadata document for
        an entire authority (as defined by <xref target="RFC3986"/>).
      </t>
      <t>
        Please discuss this draft on the
        <eref target="https://www.ietf.org/mailman/listinfo/apps-discuss">apps-discuss@ietf.org</eref>
        mailing list.
      </t>
    </section>

    <section title="Notational Conventions">
      <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="Metadata Scope">
      <t>
        The metadata returned by the host-meta resource is scoped to apply to the entire authority
        (in the URI <xref target="RFC3986"/> sense) associated with it; it does not apply to a subset, nor does it apply to other
        authorities (e.g., using another port, or a different hostname in the same domain).
      </t>
      <t>
        Protocols MAY extend the scope of a given host-meta document. For example, protocols can
        use the host-meta document served by the default (port 80) HTTP server to describe
        resources other then HTTP resources at that authority.
      </t>
    </section>

    <section title="Discovering host-meta Documents" anchor="discover">
      <t>
        The metadata for a given authority can be discovered by dereferencing the path
        '/.well-known/host-meta' on the same authority. For example, for an HTTP URI
        <xref target="RFC2616"/>, the following request would obtain metadata for the authority
        "www.example.com:80":
      </t>
      <figure>
        <artwork xml:space="preserve"><![CDATA[
    GET /.well-known/host-meta HTTP/1.1
    Host: www.example.com
]]></artwork>
      </figure>
      <t>
        The semantics of the protocol used for access to the resource apply. Therefore, if the
        resource indicates the client should try a different request (in HTTP, the 301, 302, 303 or
        307 response status code), the client SHOULD attempt to do so; note that this implies that
        the host-meta document for one authority MAY be retrieved from a different authority.
        Likewise, if the resource is not available or exists (in HTTP, the 404 or 410 status code),
        the client SHOULD infer that metadata is not available via this mechanism.
      </t>
      <t>
        If a representation is successfully obtained, but is not in the format described above,
        clients SHOULD infer that the authority is using this URI for other purposes, and not
        process it as a host-meta document.
      </t>
      <t>
        To aid in this process, authorities using this mechanism SHOULD correctly label host-meta
        responses with the "application/xrd+xml" internet media type.
      </t>
    </section>

    <section title="Document Structure">
      <t>
        [[ TBD, pending normative reference to the XRD 1.0 specification. ]]
      </t>
    </section>

    <section title="Security Considerations" anchor="Security">
      <t>
        The metadata returned by the host-meta resource is presumed to be under the control of the
        appropriate authority and representative of all resources contained by it. If this resource
        is compromised or otherwise under the control of another party, it may represent a risk to
        the security of the server and data served by it, depending on what protocols use it.
      </t>
      <t>
        Scoping metadata to a single authority is the default in host-meta. Thus "http://example.com/",
        "https://example.com", and "http://www.example.com/" all have different host-meta documents with
        seperate and non-overlapping scopes of applicability. Protocols that change the scope of
        metadata without careful consideration can incur security risks.
      </t>
    </section>

    <section title="IANA Considerations">

      <section title="The host-meta Well-Known URI">
        <t>
          This memo registers the 'host-meta' well-knwon URI in the Well-Known URI Registry as defined by
          <xref target="I-D.nottingham-site-meta" />.

          <list style="hanging">
            <t hangText="URI suffix:">
              host-meta
            </t>
            <t hangText="Change controller:">
              IETF
            </t>
            <t hangText="Specification document(s):">
              [[ this document ]]
            </t>
            <t hangText="Related information:">
              None
            </t>
          </list>
        </t>
      </section>

    </section>

    <appendix title="Acknowledgments">
      <t>
        This memo is directly based on <xref target="I-D.nottingham-site-meta" /> and incorporates
        prose written by Mark Nottingham.
      </t>
      <t>
        The author would like to acknowledge the contributions of everyone who
        provided feedback and use cases for this draft; in particular, Dirk Balfanz, DeWitt Clinton,
        Blaine Cook, Breno de Medeiros, Brad Fitzpatrick, Will Norris, John Panzer, and Drummond Reed.
      </t>
    </appendix>

    <appendix title="Document History">
      <t>
        [[ to be removed by the RFC editor before publication as an RFC ]]
      </t>
      <t>
        -00

        <list style="symbols">
          <t>
            Initial draft.
          </t>
        </list>
      </t>
    </appendix>
  
  </middle>

  <back>

    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-site-meta-03.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-P3P-20020416.xml"?>
    </references>

  </back>

</rfc>