One document matched: draft-reschke-rfc2183-in-http-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-reschke-rfc2183-in-http-00" category="std" updates="2616">
	<front>
  <title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition Header Field
  in the Hypertext Transfer Protocol (HTTP)</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>	
      <uri>http://greenbytes.de/tech/webdav/</uri>	
    </address>
  </author>

  <date month="October" year="2009" day="16"/>
  
  <abstract>
    <t>
      HTTP/1.1 defines the Content-Disposition Response Header,
      but points out that it is not part of the HTTP/1.1 Standard. 
      This specification takes over the definition and registration of
      Content-Disposition, as used in HTTP, and clarifies internationalization
      considerations.
    </t>
  </abstract>
  
  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      This specification is expected to replace the definition of Content-Disposition
      in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis
      working group. See also <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/123"/>. 
    </t>
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPbis Working Group, comments should be sent to the 
      Hypertext Transfer Protocol (HTTP) mailing list at <eref target="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</eref>,
      which may be joined by sending a message with subject 
      "subscribe" to <eref target="mailto:ietf-http-wg-request@w3.org?subject=subscribe">ietf-http-wg-request@w3.org</eref>.
    </t>
    <t>
      Discussions of the HTTPbis Working Group are archived at
      <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.               
    </t> 
    <t>
      XML versions, latest edits and the issues list for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-rfc2183-in-http"/>.
      A collection of test cases is available at <eref target="http://greenbytes.de/tech/tc2231/"/>.
    </t>
  </note>
  </front>

  <middle>

<section title="Introduction" anchor="introduction">
<t>
  HTTP/1.1 defines the Content-Disposition response header in Section 19.5.1 of <xref target="RFC2616"/>,
  but points out that is not part of the HTTP/1.1 Standard (Section 15.5):
</t>
<t><list>
  <t>
    Content-Disposition is not part of the HTTP standard, but since it is
    widely implemented, we are documenting its use and risks for implementors.
  </t>
</list></t>
<t>
  This specification takes over the definition and registration of
  Content-Disposition, as used in HTTP.
  Based on interoperability testing with existing User Agents, 
  it defines a profile of the
  features defined in the MIME variant (<xref target="RFC2183"/>) of the 
  header, and also clarifies internationalization
  considerations.
</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>
<t>
  This specification uses the augmented BNF notation defined in
  Section 2.1 of <xref target="RFC2616"/>, including its rules for
  linear whitespace (LWS).
</t>
</section>  

<section title="Header Definition" anchor="header.definition">
  <iref item="Headers" subitem="Content-Disposition" primary="true"/>
  <iref item="Content-Disposition header" primary="true"/>

<section title="Grammar">
<figure><artwork type="abnf2616"><![CDATA[
  content-disposition = "Content-Disposition" ":"
                         disposition-type *( ";" disposition-parm )

  disposition-type    = "inline" | "attachment" | disp-ext-type
                      ; case-insensitive
  disp-ext-type       = token

  disposition-parm    = filename-parm | disp-ext-parm

  filename-parm       = "filename" "=" value
                      | "filename*" "=" ext-value
  
  disp-ext-parm       = token "=" value
                      | ext-token "=" ext-value
  ext-token           = <the characters in token, followed by "*">
]]></artwork></figure>

<figure><preamble>Defined in <xref target="RFC2616"/>:</preamble><artwork type="abnf2616"><![CDATA[
  token       = <token, defined in [RFC2616], Section 2.2>
  value       = <value, defined in [RFC2616], Section 3.6>
]]></artwork></figure>
<figure><preamble>Defined in <xref target="draft-reschke-rfc2231-in-http"/>:</preamble><artwork type="abnf2616"><![CDATA[
  ext-value   = <ext-value, defined in [draft-reschke-rfc2231-in-http], Section 3.2>
]]></artwork></figure>
</section>

<section title="Disposition Type" anchor="disposition.type">
<t>
  If the disposition type matches "attachment" (case-insensitively), the
  implied suggestion is that the user agent should not display the response,
  but directly enter a "save response as..." dialog.
</t>
<t>
  On the other hand, if it matches "inline", this implies regular processing.
  Note that this type may be used when it is desirable to transport
  filename information for the case of a subsequent, user-initiated, save
  operation.
</t>
<t>
  Other disposition types SHOULD be handled the same way as "attachment"
  (<xref target="RFC2183"/>, Section 2.8).
</t>
</section>

<section title="Disposition Parameter: 'Filename'" anchor="disposition.parameter.filename">
<t>
  <cref>Talk about expected behavior, mention security considerations.</cref>
</t>
</section>

<section title="Disposition Parameter: Extensions" anchor="disposition.parameter.extensionsS">
<t>
  Parameters other then "filename" SHOULD be ignored (<xref target="RFC2183"/>, Section 2.8).
</t>
</section>

</section>  

<section title="Examples">

<figure>
<preamble>
Direct UA to show "save as" dialog, with a filename of "foo.html":  
</preamble>
<artwork type="example"><![CDATA[
Content-Disposition: Attachment; filename=foo.html
]]></artwork></figure>

<figure>
<preamble>
Direct UA to behave as if the Content-Disposition header wasn't present,
but to remember the filename "foo.html" for a subsequent save operation:
</preamble>
<artwork type="example"><![CDATA[
Content-Disposition: INLINE; FILENAME= "foo.html"
]]></artwork></figure>

<!--<figure>
<preamble>
Direct UA to show "save as" dialog, with a filename of "an example":
</preamble>
<artwork type="example">
Content-Disposition: Attachment; Filename*=UTF-8'en'an%20example
</artwork>
<postamble>Note that this uses the extended encoding defined in
<xref target="draft-reschke-rfc2231-in-http"/> to specify that the natural
language of the filename is English.
</postamble>
</figure>-->

</section>

<section title="Security Considerations" anchor="security.considerations">
<t>
  <cref anchor="csec">Both refer to 2183, and also mention: long filenames, dot and
  dotdot, absolute paths, mismatches between media type and extension</cref>
</t>
</section>  

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

<section title="Registry for Disposition Values and Parameter" anchor="regsitry">
<t>
  Section 9 of <xref target="RFC2183"/> defines the registration
  procedure for new disposition values and parameters.
</t>
</section>

<section title="Header Registration" anchor="header.registration"> 
<t>
  This document updates the definition of the Content-Disposition HTTP header
  in the permanent HTTP header registry (see <xref target="RFC3864"/>).
</t>
<t>
<list style="hanging">
  <t hangText="Header field name:">Content-Disposition</t>
  <t hangText="Applicable protocol:">http</t>
  <t hangText="Status:">standard</t>
  <t hangText="Author/Change controller:">IETF</t>
  <t hangText="Specification document:">this specification (<xref target="header.definition"/>)</t>
</list>
</t>
</section>

</section>  

<section title="Acknowledgements">
<t>
  <cref>TBD.</cref>
</t>

</section>  
  </middle>
  <back>
  
<references title="Normative References">
  
  <reference anchor="RFC2119">
    <front>
      <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
      <author initials="S." surname="Bradner" fullname="Scott Bradner">
        <organization>Harvard University</organization>
        <address><email>sob@harvard.edu</email></address>
      </author>
      <date month="March" year="1997"/>
      <area>General</area>
      <keyword>keyword</keyword>
    </front>
    <seriesInfo name="BCP" value="14"/>
    <seriesInfo name="RFC" value="2119"/>
  </reference>

  <reference anchor="RFC2183">
    <front>
      <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
      <author initials="R." surname="Troost" fullname="Rens Troost">
        <organization>New Century Systems</organization>
        <address><email>rens@century.com</email></address>
      </author>
      <author initials="S." surname="Dorner" fullname="Steve Dorner">
        <organization>QUALCOMM Incorporated</organization>
        <address><email>sdorner@qualcomm.com</email></address>
      </author>
      <author initials="K." surname="Moore" fullname="Keith Moore">
        <organization>Department of Computer Science</organization>
        <address><email>moore@cs.utk.edu</email></address>
      </author>
      <date year="1997" month="August"/>
    </front>
    <seriesInfo name="RFC" value="2183"/>
  </reference>

  <reference anchor="RFC2616">
    <front>
      <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
      <author initials="R." surname="Fielding" fullname="R. Fielding">
        <organization>University of California, Irvine</organization>
        <address><email>fielding@ics.uci.edu</email></address>
      </author>
      <author initials="J." surname="Gettys" fullname="J. Gettys">
        <organization>W3C</organization>
        <address><email>jg@w3.org</email></address>
      </author>
      <author initials="J." surname="Mogul" fullname="J. Mogul">
        <organization>Compaq Computer Corporation</organization>
        <address><email>mogul@wrl.dec.com</email></address>
      </author>
      <author initials="H." surname="Frystyk" fullname="H. Frystyk">
        <organization>MIT Laboratory for Computer Science</organization>
        <address><email>frystyk@w3.org</email></address>
      </author>
      <author initials="L." surname="Masinter" fullname="L. Masinter">
        <organization>Xerox Corporation</organization>
        <address><email>masinter@parc.xerox.com</email></address>
      </author>
      <author initials="P." surname="Leach" fullname="P. Leach">
        <organization>Microsoft Corporation</organization>
        <address><email>paulle@microsoft.com</email></address>
      </author>
      <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
        <organization>W3C</organization>
        <address><email>timbl@w3.org</email></address>
      </author>
      <date month="June" year="1999"/>
    </front>
    <seriesInfo name="RFC" value="2616"/>
  </reference>

  <reference anchor="draft-reschke-rfc2231-in-http">
  	<front>
      <title abbrev="RFC2231 Encoding in HTTP">Applicability of RFC 2231
      Encoding to Hypertext Transfer Protocol (HTTP) Headers</title>
      <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
        <organization abbrev="greenbytes">greenbytes GmbH</organization>
        <address>
          <postal>
            <street>Hafenweg 16</street>
            <city>Muenster</city><region>NW</region><code>48155</code>
            <country>Germany</country>
          </postal>
          <email>julian.reschke@greenbytes.de</email>	
          <uri>http://greenbytes.de/tech/webdav/</uri>	
        </address>
      </author>
    
      <date month="October" year="2009"/>
    </front>
    <seriesInfo name="Internet-Draft" value="draft-reschke-rfc2231-in-http-05"/>
    
  </reference>
  
</references>
  
<references title="Informative References">

  <reference anchor="RFC3864">
    <front>
      <title>Registration Procedures for Message Header Fields</title>
      <author initials="G." surname="Klyne" fullname="G. Klyne">
        <organization>Nine by Nine</organization>
        <address><email>GK-IETF@ninebynine.org</email></address>
      </author>
      <author initials="M." surname="Nottingham" fullname="M. Nottingham">
        <organization>BEA Systems</organization>
        <address><email>mnot@pobox.com</email></address>
      </author>
      <author initials="J." surname="Mogul" fullname="J. Mogul">
        <organization>HP Labs</organization>
        <address><email>JeffMogul@acm.org</email></address>
      </author>
      <date year="2004" month="September"/>
    </front>
    <seriesInfo name="BCP" value="90"/>
    <seriesInfo name="RFC" value="3864"/>
  </reference>

</references>

<section title="Changes from the RFC 2616 Definition" anchor="changes.from.rfc2616">
<t>
  Compared to Section 19.5.1 of <xref target="RFC2616"/>, the following
  normative changes reflecting actual implementations have been made:
<list style="symbols">
  <t>
    According to RFC 2616, the disposition type "attachment" only applies to
    content of type "application/octet-stream". This restriction has been 
    removed, because user agents in practice do not check the content type, and
    it also discourages properly declaring the media type.
  </t>
  <t>
    The definition for the disposition type "inline" (<xref target="RFC2183"/>, Section 2.1)
    has been re-added with a suggestion for its processing.
  </t>
  <t>
    This specification requires support for the extended parameter encoding
    defined in <xref target="draft-reschke-rfc2231-in-http"/>.
  </t>
</list>
</t>
</section>

<section title="Differences compared to RFC 2183" anchor="diffs.compared.to.rfc2183">
<t>
  Section 2 of <xref target="RFC2183"/> defines several additional
  disposition parameters: "creation-date", "modification-date",
  "quoted-date-time", and "size". These do not appear to be implemented by
  any user agent, thus have been ommitted from this specification.
</t>
</section>

<section title="Alternative Approaches to Filename Escaping">
<t>
  <cref>Mention: RFC 2047, IE, Safari</cref>
</t>
</section>


  </back>

</rfc>