Context Navigation

← Previous Change
Next Change →

Changeset 2726 for draft-ietf-httpbis-content-disp/05

Timestamp:

14/06/14 11:20:37 (6 years ago)

Author:

julian.reschke@…

Message:

update to latest version of rfc2629.xslt, regen all HTML

File:

: 1 edited

draft-ietf-httpbis-content-disp/05/draft-ietf-httpbis-content-disp.html (modified) (32 diffs)

Legend:

: Unmodified
: Added
: Removed

draft-ietf-httpbis-content-disp/05/draft-ietf-httpbis-content-disp.html

-                      r1119
+                      r2726
   PUBLIC "-//W3C//DTD HTML 4.01//EN">
 <html lang="en">
    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
+   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
       <title>Use of the Content-Disposition&nbsp;Header&nbsp;Field
 …
 body {
   color: black;
+  font-family: verdana, helvetica, arial, sans-serif;
+  font-size: 10pt;
+  font-family: cambria, helvetica, arial, sans-serif;
+  font-size: 11pt;
+  margin-right: 2em;
+}
 cite {
 …
   margin-left: 2em;
+}
-dd {
-  margin-right: 2em;
+}
 dl {
   margin-left: 2em;
+}
 ul.empty {
   list-style-type: none;
 …
+}
 h1 {
   font-size: 14pt;
+  font-size: 130%;
   line-height: 21pt;
   page-break-after: avoid;
 …
   page-break-before: always;
+}
-h1 a {
-  color: #333333;
+}
 h2 {
   font-size: 12pt;
+  font-size: 120%;
   line-height: 15pt;
   page-break-after: avoid;
+}
 h3, h4, h5, h6 {
   font-size: 10pt;
+h3 {
+  font-size: 110%;
   page-break-after: avoid;
+}
+h2 a, h3 a, h4 a, h5 a, h6 a {
+h4, h5, h6 {
+  page-break-after: avoid;
+}
+h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
   color: black;
+}
 …
 li {
   margin-left: 2em;
-  margin-right: 2em;
+}
 ol {
   margin-left: 2em;
+  margin-right: 2em;
+}
+ol.la {
+  list-style-type: lower-alpha;
+}
+ol.ua {
+  list-style-type: upper-alpha;
+}
 ol p {
 …
 p {
   margin-left: 2em;
-  margin-right: 2em;
+}
 pre {
 …
   background-color: lightyellow;
   padding: .25em;
+  page-break-inside: avoid;
+}
 pre.text2 {
 …
 table.tt {
   vertical-align: top;
+  border-color: gray;
+}
+table.tt th {
+  border-color: gray;
+}
+table.tt td {
+  border-color: gray;
+}
+table.all {
+  border-style: solid;
+  border-width: 2px;
+}
 table.full {
+  border-style: outset;
+  border-width: 1px;
+}
+table.headers {
+  border-style: outset;
+  border-width: 1px;
+  border-style: solid;
+  border-width: 2px;
+}
 table.tt td {
   vertical-align: top;
+}
+table.all td {
+  border-style: solid;
+  border-width: 1px;
+}
 table.full td {
   border-style: inset;
+  border-style: none solid;
   border-width: 1px;
+}
 …
   vertical-align: top;
+}
+table.all th {
+  border-style: solid;
+  border-width: 1px;
+}
 table.full th {
   border-style: inset;
   border-width: 1px;
+  border-style: solid;
+  border-width: 1px 1px 2px 1px;
+}
 table.headers th {
   border-style: none none inset none;
   border-width: 1px;
+  border-style: none none solid none;
+  border-width: 2px;
+}
 table.left {
 …
   caption-side: bottom;
   font-weight: bold;
   font-size: 9pt;
+  font-size: 10pt;
   margin-top: .5em;
+}
 …
   border-spacing: 1px;
   width: 95%;
   font-size: 10pt;
+  font-size: 11pt;
   color: white;
+}
 …
 td.topnowrap {
   vertical-align: top;
   white-space: nowrap;
+  white-space: nowrap;
+}
 table.header td {
 …
   list-style: none;
   margin-left: 1.5em;
-  margin-right: 0em;
   padding-left: 0em;
+}
 …
   line-height: 150%;
   font-weight: bold;
-  font-size: 10pt;
   margin-left: 0em;
-  margin-right: 0em;
+}
 ul.toc li li {
   line-height: normal;
   font-weight: normal;
   font-size: 9pt;
+  font-size: 10pt;
   margin-left: 0em;
-  margin-right: 0em;
+}
 li.excluded {
 …
 ul p {
   margin-left: 0em;
+}
+.title, .filename, h1, h2, h3, h4 {
+  font-family: candara, helvetica, arial, sans-serif;
+}
+samp, tt, code, pre {
+  font: consolas, monospace;
+}
 ul.ind, ul.ind ul {
   list-style: none;
   margin-left: 1.5em;
-  margin-right: 0em;
   padding-left: 0em;
   page-break-before: avoid;
 …
   line-height: 200%;
   margin-left: 0em;
-  margin-right: 0em;
+}
 ul.ind li li {
 …
   line-height: 150%;
   margin-left: 0em;
-  margin-right: 0em;
+}
 .avoidbreak {
 …
   font-weight: bold;
   text-align: center;
   font-size: 9pt;
+  font-size: 10pt;
+}
 .filename {
   color: #333333;
+  font-size: 75%;
   font-weight: bold;
-  font-size: 12pt;
   line-height: 21pt;
   text-align: center;
 …
   font-weight: bold;
+}
-.hidden {
-  display: none;
+}
 .left {
   text-align: left;
 …
+}
 .title {
   color: #990000;
   font-size: 18pt;
+  color: green;
+  font-size: 150%;
   line-height: 18pt;
   font-weight: bold;
 …
   margin-top: 36pt;
+}
-.vcardline {
-  display: block;
+}
 .warning {
   font-size: 14pt;
+  font-size: 130%;
   background-color: yellow;
+}
 …
     display: none;
+  }
   a {
     color: black;
 …
     background-color: white;
     vertical-align: top;
     font-size: 12pt;
+  }
   ul.toc a::after {
+    font-size: 110%;
+  }
+  ul.toc a:nth-child(2)::after {
     content: leader('.') target-counter(attr(href), page);
+  }
   ul.ind li li a {
     content: target-counter(attr(href), page);
+  }
   .print2col {
     column-count: 2;
 …
 @page {
   @top-left {
        content: "Internet-Draft";
+  }
+       content: "Internet-Draft";
+  }
   @top-right {
        content: "February 2011";
+  }
+       content: "February 2011";
+  }
   @top-center {
        content: "Content-Disposition in HTTP";
+  }
+       content: "Content-Disposition in HTTP";
+  }
   @bottom-left {
        content: "Reschke";
+  }
+       content: "Reschke";
+  }
   @bottom-center {
        content: "Expires August 21, 2011";
+  }
+       content: "Expires August 21, 2011";
+  }
   @bottom-right {
        content: "[Page " counter(page) "]";
+  }
+}
 @page:first {
+       content: "[Page " counter(page) "]";
+  }
+}
+@page:first {
     @top-left {
       content: normal;
 …
       <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C">
       <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.540, 2011-01-10 09:27:20, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <meta name="dct.creator" content="Reschke, J. F.">
 …
             </tr>
             <tr>
                <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
+               <td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2616">2616</a> (if approved)
                </td>
                <td class="right">February 17, 2011</td>
 …
       </table>
       <p class="title">Use of the Content-Disposition&nbsp;Header&nbsp;Field in the Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP)<br><span class="filename">draft-ietf-httpbis-content-disp-05</span></p>
       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
+      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
       <p>HTTP/1.1 defines the Content-Disposition response header field, 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
          aspects.
       </p>
       <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor before publication)</a></h1>
+      </p>
+      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor before publication)</a></h1>
       <p>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 &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123</a>&gt;.
       </p>
+      </p>
       <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues
          list is at &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp">http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
       </p>
+      </p>
       <p>The changes in this draft are summarized in <a href="#changes.since.04" title="Since draft-ietf-httpbis-content-disp-04">Appendix&nbsp;D.9</a>.
-      </p>
-      <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
-      <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
-      <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
-         working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
       </p>
+      <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
+         documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
+         in progress”.
+      </p>
+      <p>This Internet-Draft will expire on August 21, 2011.</p>
+      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
+      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
+      <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
+         and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
+         text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
+         BSD License.
+      </p>
+      <div id="rfc.status">
+         <h1><a href="#rfc.status">Status of This Memo</a></h1>
+         <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
+         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
+            working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
+         </p>
+         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
+            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
+            in progress”.
+         </p>
+         <p>This Internet-Draft will expire on August 21, 2011.</p>
+      </div>
+      <div id="rfc.copyrightnotice">
+         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
+         <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
+         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
+            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
+            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
+            BSD License.
+         </p>
+      </div>
       <hr class="noprint">
       <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
       <ul class="toc">
          <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li>
          <li>2.&nbsp;&nbsp;&nbsp;<a href="#notational.conventions">Notational Conventions</a></li>
          <li>3.&nbsp;&nbsp;&nbsp;<a href="#conformance.and.error.handling">Conformance and Error Handling</a></li>
          <li>4.&nbsp;&nbsp;&nbsp;<a href="#header.field.definition">Header Field Definition</a><ul>
                <li>4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Grammar</a></li>
                <li>4.2&nbsp;&nbsp;&nbsp;<a href="#disposition.type">Disposition Type</a></li>
                <li>4.3&nbsp;&nbsp;&nbsp;<a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></li>
                <li>4.4&nbsp;&nbsp;&nbsp;<a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></li>
                <li>4.5&nbsp;&nbsp;&nbsp;<a href="#extensibility">Extensibility</a></li>
+         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li>
+         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#notational.conventions">Notational Conventions</a></li>
+         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#conformance.and.error.handling">Conformance and Error Handling</a></li>
+         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definition">Header Field Definition</a><ul>
+               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Grammar</a></li>
+               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#disposition.type">Disposition Type</a></li>
+               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></li>
+               <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></li>
+               <li><a href="#rfc.section.4.5">4.5</a>&nbsp;&nbsp;&nbsp;<a href="#extensibility">Extensibility</a></li>
             </ul>
          </li>
          <li>5.&nbsp;&nbsp;&nbsp;<a href="#examples">Examples</a></li>
          <li>6.&nbsp;&nbsp;&nbsp;<a href="#i18n">Internationalization Considerations</a></li>
          <li>7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
          <li>8.&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameter</a></li>
                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
+         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#examples">Examples</a></li>
+         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#i18n">Internationalization Considerations</a></li>
+         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
+         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
+               <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameter</a></li>
+               <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
             </ul>
          </li>
          <li>9.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9">Acknowledgements</a></li>
          <li>10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
+         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9">Acknowledgements</a></li>
+         <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
+               <li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
+               <li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
             </ul>
          </li>
+         <li><a href="#rfc.authors">Author's Address</a></li>
+         <li>A.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li>
+         <li>B.&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li>
+         <li>C.&nbsp;&nbsp;&nbsp;<a href="#alternatives">Alternative Approaches to Internationalization</a><ul>
+               <li>C.1&nbsp;&nbsp;&nbsp;<a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li>
+               <li>C.2&nbsp;&nbsp;&nbsp;<a href="#alternatives.percent">Percent Encoding</a></li>
+               <li>C.3&nbsp;&nbsp;&nbsp;<a href="#alternatives.sniff">Encoding Sniffing</a></li>
+               <li>C.4&nbsp;&nbsp;&nbsp;<a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></li>
+         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li>
+         <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li>
+         <li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#alternatives">Alternative Approaches to Internationalization</a><ul>
+               <li><a href="#rfc.section.C.1">C.1</a>&nbsp;&nbsp;&nbsp;<a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li>
+               <li><a href="#rfc.section.C.2">C.2</a>&nbsp;&nbsp;&nbsp;<a href="#alternatives.percent">Percent Encoding</a></li>
+               <li><a href="#rfc.section.C.3">C.3</a>&nbsp;&nbsp;&nbsp;<a href="#alternatives.sniff">Encoding Sniffing</a></li>
+               <li><a href="#rfc.section.C.4">C.4</a>&nbsp;&nbsp;&nbsp;<a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></li>
             </ul>
          </li>
          <li>D.&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
                <li>D.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.1">Since draft-reschke-rfc2183-in-http-00</a></li>
                <li>D.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.2">Since draft-reschke-rfc2183-in-http-01</a></li>
                <li>D.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.3">Since draft-reschke-rfc2183-in-http-02</a></li>
                <li>D.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.4">Since draft-reschke-rfc2183-in-http-03</a></li>
                <li>D.5&nbsp;&nbsp;&nbsp;<a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></li>
                <li>D.6&nbsp;&nbsp;&nbsp;<a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></li>
                <li>D.7&nbsp;&nbsp;&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></li>
                <li>D.8&nbsp;&nbsp;&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></li>
                <li>D.9&nbsp;&nbsp;&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></li>
+         <li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
+               <li><a href="#rfc.section.D.1">D.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.1">Since draft-reschke-rfc2183-in-http-00</a></li>
+               <li><a href="#rfc.section.D.2">D.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.2">Since draft-reschke-rfc2183-in-http-01</a></li>
+               <li><a href="#rfc.section.D.3">D.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.3">Since draft-reschke-rfc2183-in-http-02</a></li>
+               <li><a href="#rfc.section.D.4">D.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.D.4">Since draft-reschke-rfc2183-in-http-03</a></li>
+               <li><a href="#rfc.section.D.5">D.5</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></li>
+               <li><a href="#rfc.section.D.6">D.6</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></li>
+               <li><a href="#rfc.section.D.7">D.7</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></li>
+               <li><a href="#rfc.section.D.8">D.8</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></li>
+               <li><a href="#rfc.section.D.9">D.9</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></li>
             </ul>
          </li>
          <li><a href="#rfc.index">Index</a></li>
+         <li><a href="#rfc.authors">Author's Address</a></li>
       </ul>
+      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
+      <p id="rfc.section.1.p.1">HTTP/1.1 defines the Content-Disposition response header field in <a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, but points out that it is not part of the HTTP/1.1 Standard (<a href="http://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>):
+      </p>
+      <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5">
+         <p>Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks
+            for implementers.
+         </p>
+      </blockquote>
+      <p id="rfc.section.1.p.3">This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability
+         testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions
+         (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects.
+      </p>
+      <div class="note" id="rfc.section.1.p.4">
+         <p> <b>Note:</b> this document does not apply to Content-Disposition header fields appearing in message payloads transmitted over HTTP, such
+            as when using the media type "multipart/form-data" (<a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>).
+         </p>
+      </div>
+      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="notational.conventions" href="#notational.conventions">Notational Conventions</a></h1>
+      <p id="rfc.section.2.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
+      </p>
+      <p id="rfc.section.2.p.2">This specification uses the augmented BNF notation defined in <a href="http://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, including its rules for implied linear whitespace (LWS).
+      </p>
+      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="conformance.and.error.handling" href="#conformance.and.error.handling">Conformance and Error Handling</a></h1>
+      <p id="rfc.section.3.p.1">This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP
+         user agents) of the Content-Location header field. An implementation is considered conformant if it complies with all of the
+         requirements associated with its role.
+      </p>
+      <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements,
+         but it does not define special handling of these invalid field-values.
+      </p>
+      <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Location header fields that are invalid.
+      </p>
+      <p id="rfc.section.3.p.4">Consuming implementations <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such,
+         the default handling of invalid fields is to ignore them.
+      </p>
+      <div id="rfc.iref.h.1"></div>
+      <div id="rfc.iref.c.1"></div>
+      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definition" href="#header.field.definition">Header Field Definition</a></h1>
+      <p id="rfc.section.4.p.1">The Content-Disposition response header field is used to convey additional information about how to process the response payload,
+         and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.
+      </p>
+      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Grammar
+      </h2>
+      <div id="rfc.figure.u.1"></div><pre class="inline">  content-disposition = "Content-Disposition" ":"
+      <div id="introduction">
+         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1>
+         <p id="rfc.section.1.p.1">HTTP/1.1 defines the Content-Disposition response header field in <a href="https://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, but points out that it is not part of the HTTP/1.1 Standard (<a href="https://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>):
+         </p>
+         <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5">
+            <p>Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks
+               for implementers.
+            </p>
+         </blockquote>
+         <p id="rfc.section.1.p.3">This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability
+            testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions
+            (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects.
+         </p>
+         <div class="note" id="rfc.section.1.p.4">
+            <p><b>Note:</b> this document does not apply to Content-Disposition header fields appearing in message payloads transmitted over HTTP, such
+               as when using the media type "multipart/form-data" (<a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>).
+            </p>
+         </div>
+      </div>
+      <div id="notational.conventions">
+         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#notational.conventions">Notational Conventions</a></h1>
+         <p id="rfc.section.2.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
+         </p>
+         <p id="rfc.section.2.p.2">This specification uses the augmented BNF notation defined in <a href="https://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, including its rules for implied linear whitespace (LWS).
+         </p>
+      </div>
+      <div id="conformance.and.error.handling">
+         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#conformance.and.error.handling">Conformance and Error Handling</a></h1>
+         <p id="rfc.section.3.p.1">This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP
+            user agents) of the Content-Location header field. An implementation is considered conformant if it complies with all of the
+            requirements associated with its role.
+         </p>
+         <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements,
+            but it does not define special handling of these invalid field-values.
+         </p>
+         <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Location header fields that are invalid.
+         </p>
+         <p id="rfc.section.3.p.4">Consuming implementations <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such,
+            the default handling of invalid fields is to ignore them.
+         </p>
+      </div>
+      <div id="header.field.definition">
+         <div id="rfc.iref.h.1"></div>
+         <div id="rfc.iref.c.1"></div>
+         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#header.field.definition">Header Field Definition</a></h1>
+         <p id="rfc.section.4.p.1">The Content-Disposition response header field is used to convey additional information about how to process the response payload,
+            and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.
+         </p>
+         <div>
+            <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Grammar
+            </h2>
+            <div id="rfc.figure.u.1"></div><pre class="inline">  content-disposition = "Content-Disposition" ":"
                          disposition-type *( ";" disposition-parm )
 …
                       | ext-token "=" ext-value
   ext-token           = &lt;the characters in token, followed by "*"&gt;
 </pre><div id="rfc.figure.u.2"></div>
       <p>Defined in <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>:
       </p>  <pre class="inline">  token         = &lt;token, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>&gt;
   quoted-string = &lt;quoted-string, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>&gt;
   value         = &lt;value, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.6">Section 3.6</a>&gt;
+</pre><div id="rfc.figure.u.2"></div>
+            <p>Defined in <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>:
+            </p><pre class="inline">  token         = &lt;token, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>&gt;
+  quoted-string = &lt;quoted-string, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>&gt;
+  value         = &lt;value, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-3.6">Section 3.6</a>&gt;
                 ; token | quoted-string
 </pre><div id="rfc.figure.u.3"></div>
       <p>Defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>:
       </p>  <pre class="inline">  ext-value   = &lt;ext-value, defined in <a href="#RFC5987" id="rfc.xref.RFC5987.2"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, <a href="http://tools.ietf.org/html/rfc5987#section-3.2">Section 3.2</a>&gt;
+</pre><div id="rfc.figure.u.3"></div>
+            <p>Defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>:
+            </p><pre class="inline">  ext-value   = &lt;ext-value, defined in <a href="#RFC5987" id="rfc.xref.RFC5987.2"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, <a href="https://tools.ietf.org/html/rfc5987#section-3.2">Section 3.2</a>&gt;
 </pre><p id="rfc.section.4.1.p.4">Header field values with multiple instances of the same parameter name are invalid.</p>
+      <p id="rfc.section.4.1.p.5">Note that due to the rules for implied linear whitespace (<a href="http://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters.
+      </p>
+      <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language; this is of limited use for filenames
+         and is likely to be ignored by recipients.
+      </p>
+      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="disposition.type" href="#disposition.type">Disposition Type</a></h2>
+      <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user
+         to save the response locally, rather than process it normally (as per its media type).
+      </p>
+      <p id="rfc.section.4.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p>
+      <p id="rfc.section.4.2.p.3">Unknown or unhandled disposition types <em class="bcp14">SHOULD</em> be handled by recipients the same way as "attachment" (see also <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>).
+      </p>
+      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="disposition.parameter.filename" href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></h2>
+      <p id="rfc.section.4.3.p.1">The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename
+         for storing the message payload.
+      </p>
+      <p id="rfc.section.4.3.p.2">Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the
+         "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page
+         being displayed).
+      </p>
+      <p id="rfc.section.4.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>).
+      </p>
+      <p id="rfc.section.4.3.p.4">Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when
+         both "filename" and "filename*" are present in a single header field value, recipients <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the
+         more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section&nbsp;5</a> for an example).
+      </p>
+      <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired
+         information. In particular:
+      </p>
+      <ul>
+         <li>
+            <p>When the value contains path separator characters ("\" or "/"), recipients <em class="bcp14">SHOULD</em> ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as
+               "/etc/passwd").
+            </p>
+         </li>
+         <li>
+            <p>Many platforms do not use Internet Media Types (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file
+               extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients need
+               to ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
+            </p>
+         </li>
+         <li>
+            <p>Recipients are advised to strip or replace character sequences that are known to cause confusion both in user interfaces and
+               in filenames, such as control characters and leading and trailing whitespace.
+            </p>
+         </li>
+         <li>
+            <p>Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands,
+               such as "." and "..", "~", "|", and also device names.
+            </p>
+         </li>
+      </ul>
+      <div class="note" id="rfc.section.4.3.p.6">
+         <p> <b>Note:</b> Many user agents do not properly handle escape characters when using the quoted-string form. Furthermore, some user agents
+            erroneously try to perform unescaping of "percent" escapes (see <a href="#alternatives.percent" title="Percent Encoding">Appendix&nbsp;C.2</a>), and thus might misinterpret filenames containing the percent character followed by two hex digits.
+         </p>
+      </div>
+      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="disposition.parameter.extensions" href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></h2>
+      <p id="rfc.section.4.4.p.1">To enable future extensions, recipients <em class="bcp14">SHOULD</em> ignore unrecognized parameters (see also <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>).
+      </p>
+      <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="extensibility" href="#extensibility">Extensibility</a></h2>
+      <p id="rfc.section.4.5.p.1">Note that <a href="http://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.4"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols
+         using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP.
+      </p>
+      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="examples" href="#examples">Examples</a></h1>
+      <div id="rfc.figure.u.4"></div>
+      <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p>  <pre class="text">Content-Disposition: Attachment; filename=example.html
+</pre><div id="rfc.figure.u.5"></div>
+      <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html"
+         for a subsequent save operation:
+      </p>  <pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html"
+</pre>  <p>Note: this uses the quoted-string form so that the space character can be included.</p>
+      <div id="rfc.figure.u.6"></div>
+      <p>Direct UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p>  <pre class="text">Content-Disposition: attachment;
+            <p id="rfc.section.4.1.p.5">Note that due to the rules for implied linear whitespace (<a href="https://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters.
+            </p>
+            <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language; this is of limited use for filenames
+               and is likely to be ignored by recipients.
+            </p>
+         </div>
+         <div id="disposition.type">
+            <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#disposition.type">Disposition Type</a></h2>
+            <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user
+               to save the response locally, rather than process it normally (as per its media type).
+            </p>
+            <p id="rfc.section.4.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p>
+            <p id="rfc.section.4.2.p.3">Unknown or unhandled disposition types <em class="bcp14">SHOULD</em> be handled by recipients the same way as "attachment" (see also <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>).
+            </p>
+         </div>
+         <div id="disposition.parameter.filename">
+            <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></h2>
+            <p id="rfc.section.4.3.p.1">The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename
+               for storing the message payload.
+            </p>
+            <p id="rfc.section.4.3.p.2">Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the
+               "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page
+               being displayed).
+            </p>
+            <p id="rfc.section.4.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>).
+            </p>
+            <p id="rfc.section.4.3.p.4">Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when
+               both "filename" and "filename*" are present in a single header field value, recipients <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the
+               more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section&nbsp;5</a> for an example).
+            </p>
+            <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired
+               information. In particular:
+            </p>
+            <ul>
+               <li>
+                  <p>When the value contains path separator characters ("\" or "/"), recipients <em class="bcp14">SHOULD</em> ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as
+                     "/etc/passwd").
+                  </p>
+               </li>
+               <li>
+                  <p>Many platforms do not use Internet Media Types (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file
+                     extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients need
+                     to ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
+                  </p>
+               </li>
+               <li>
+                  <p>Recipients are advised to strip or replace character sequences that are known to cause confusion both in user interfaces and
+                     in filenames, such as control characters and leading and trailing whitespace.
+                  </p>
+               </li>
+               <li>
+                  <p>Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands,
+                     such as "." and "..", "~", "|", and also device names.
+                  </p>
+               </li>
+            </ul>
+            <div class="note" id="rfc.section.4.3.p.6">
+               <p><b>Note:</b> Many user agents do not properly handle escape characters when using the quoted-string form. Furthermore, some user agents
+                  erroneously try to perform unescaping of "percent" escapes (see <a href="#alternatives.percent" title="Percent Encoding">Appendix&nbsp;C.2</a>), and thus might misinterpret filenames containing the percent character followed by two hex digits.
+               </p>
+            </div>
+         </div>
+         <div id="disposition.parameter.extensions">
+            <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></h2>
+            <p id="rfc.section.4.4.p.1">To enable future extensions, recipients <em class="bcp14">SHOULD</em> ignore unrecognized parameters (see also <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>).
+            </p>
+         </div>
+         <div id="extensibility">
+            <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a href="#extensibility">Extensibility</a></h2>
+            <p id="rfc.section.4.5.p.1">Note that <a href="https://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.4"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols
+               using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP.
+            </p>
+         </div>
+      </div>
+      <div id="examples">
+         <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#examples">Examples</a></h1>
+         <div id="rfc.figure.u.4"></div>
+         <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p><pre class="text">Content-Disposition: Attachment; filename=example.html
+</pre><div id="rfc.figure.u.5"></div>
+         <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html"
+            for a subsequent save operation:
+         </p><pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html"
+</pre><p>Note: this uses the quoted-string form so that the space character can be included.</p>
+         <div id="rfc.figure.u.6"></div>
+         <p>Direct UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p><pre class="text">Content-Disposition: attachment;
                      filename*= UTF-8''<b>%e2%82%ac</b>%20rates
 </pre>  <p>Here, the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.4"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> is also used to encode the non-ISO-8859-1 character.
       </p>
       <div id="rfc.figure.u.7"></div>
       <p>Same as above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:</p>  <pre class="text">Content-Disposition: attachment;
+</pre><p>Here, the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.4"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> is also used to encode the non-ISO-8859-1 character.
+         </p>
+         <div id="rfc.figure.u.7"></div>
+         <p>Same as above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:</p><pre class="text">Content-Disposition: attachment;
                      filename="EURO rates";
                      filename*=utf-8''<b>%e2%82%ac</b>%20rates
+</pre>  <p>Note: as of February 2011, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after
+         "filename". Unfortunately, some user agents that do support RFC 5987 do pick the "filename" rather than the "filename*" parameter
+         when it occurs first; it is expected that this situation is going to improve soon.
+      </p>
+      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="i18n" href="#i18n">Internationalization Considerations</a></h1>
+      <p id="rfc.section.6.p.1">The "filename*" parameter (<a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>), using the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.5"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language
+         in use.
+      </p>
+      <p id="rfc.section.6.p.2">Future parameters might also require internationalization, in which case the same encoding can be used.</p>
+      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
+      <p id="rfc.section.7.p.1">Using server-supplied information for constructing local filenames introduces many risks. These are summarized in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>.
+      </p>
+      <p id="rfc.section.7.p.2">Furthermore, implementers also ought to be aware of the Security Considerations applying to HTTP (see <a href="http://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="http://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>).
+      </p>
+      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
+      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="registry" href="#registry">Registry for Disposition Values and Parameter</a></h2>
+      <p id="rfc.section.8.1.p.1">This specification does not introduce any changes to the registration procedures for disposition values and parameters that
+         are defined in <a href="http://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.5"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
+      </p>
+      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
+      <p id="rfc.section.8.2.p.1">This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry
+         (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>).
+      </p>
+      <p id="rfc.section.8.2.p.2"> </p>
+      <dl>
+         <dt>Header field name:</dt>
+         <dd>Content-Disposition</dd>
+         <dt>Applicable protocol:</dt>
+         <dd>http</dd>
+         <dt>Status:</dt>
+         <dd>standard</dd>
+         <dt>Author/Change controller:</dt>
+         <dd>IETF</dd>
+         <dt>Specification document:</dt>
+         <dd>this specification (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section&nbsp;4</a>)
+         </dd>
+      </dl>
+      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;Acknowledgements
+      </h1>
+      <p id="rfc.section.9.p.1">Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham
+         for their valuable feedback.
+      </p>
+</pre><p>Note: as of February 2011, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after
+            "filename". Unfortunately, some user agents that do support RFC 5987 do pick the "filename" rather than the "filename*" parameter
+            when it occurs first; it is expected that this situation is going to improve soon.
+         </p>
+      </div>
+      <div id="i18n">
+         <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#i18n">Internationalization Considerations</a></h1>
+         <p id="rfc.section.6.p.1">The "filename*" parameter (<a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>), using the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.5"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language
+            in use.
+         </p>
+         <p id="rfc.section.6.p.2">Future parameters might also require internationalization, in which case the same encoding can be used.</p>
+      </div>
+      <div id="security.considerations">
+         <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
+         <p id="rfc.section.7.p.1">Using server-supplied information for constructing local filenames introduces many risks. These are summarized in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>.
+         </p>
+         <p id="rfc.section.7.p.2">Furthermore, implementers also ought to be aware of the Security Considerations applying to HTTP (see <a href="https://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="https://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>).
+         </p>
+      </div>
+      <div id="iana.considerations">
+         <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1>
+         <div id="registry">
+            <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a href="#registry">Registry for Disposition Values and Parameter</a></h2>
+            <p id="rfc.section.8.1.p.1">This specification does not introduce any changes to the registration procedures for disposition values and parameters that
+               are defined in <a href="https://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.5"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
+            </p>
+         </div>
+         <div id="header.field.registration">
+            <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2>
+            <p id="rfc.section.8.2.p.1">This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry
+               (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>).
+            </p>
+            <p id="rfc.section.8.2.p.2"></p>
+            <dl>
+               <dt>Header field name:</dt>
+               <dd>Content-Disposition</dd>
+               <dt>Applicable protocol:</dt>
+               <dd>http</dd>
+               <dt>Status:</dt>
+               <dd>standard</dd>
+               <dt>Author/Change controller:</dt>
+               <dd>IETF</dd>
+               <dt>Specification document:</dt>
+               <dd>this specification (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section&nbsp;4</a>)
+               </dd>
+            </dl>
+         </div>
+      </div>
+      <div>
+         <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;Acknowledgements
+         </h1>
+         <p id="rfc.section.9.p.1">Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham
+            for their valuable feedback.
+         </p>
+      </div>
       <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
       </h1>
       <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
       </h2>
       <table>
+      <table>
          <tr>
             <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
 …
          <tr>
             <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
+            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
             <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
+            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC5987">[RFC5987]</b></td>
             <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC&nbsp;5987, August&nbsp;2010.
+            <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="https://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC&nbsp;5987, August&nbsp;2010.
             </td>
          </tr>
 …
       <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
       </h2>
       <table>
+      <table>
          <tr>
             <td class="reference"><b id="RFC2046">[RFC2046]</b></td>
             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.
+            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="https://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC2047">[RFC2047]</b></td>
             <td class="top"><a href="mailto:moore@cs.utk.edu" title="University of Tennessee">Moore, K.</a>, “<a href="http://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC&nbsp;2047, November&nbsp;1996.
+            <td class="top"><a href="mailto:moore@cs.utk.edu" title="University of Tennessee">Moore, K.</a>, “<a href="https://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC&nbsp;2047, November&nbsp;1996.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC2183">[RFC2183]</b></td>
             <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC&nbsp;2183, August&nbsp;1997.
+            <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore</a>, “<a href="https://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC&nbsp;2183, August&nbsp;1997.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC2231">[RFC2231]</b></td>
             <td class="top"><a href="mailto:ned.freed@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:moore@cs.utk.edu" title="University of Tennessee">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2231">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</a>”, RFC&nbsp;2231, November&nbsp;1997.
+            <td class="top"><a href="mailto:ned.freed@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:moore@cs.utk.edu" title="University of Tennessee">K. Moore</a>, “<a href="https://tools.ietf.org/html/rfc2231">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</a>”, RFC&nbsp;2231, November&nbsp;1997.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC2388">[RFC2388]</b></td>
             <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC&nbsp;2388, August&nbsp;1998.
+            <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="https://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC&nbsp;2388, August&nbsp;1998.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC3864">[RFC3864]</b></td>
             <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.
+            <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.
             </td>
          </tr>
          <tr>
             <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
             <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
+            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
             </td>
          </tr>
       </table>
+      <div class="avoidbreak">
+         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
+         <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span><span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
+      </div>
+      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="changes.from.rfc2616" href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></h1>
+      <p id="rfc.section.A.p.1">Compared to <a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.10"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, the following normative changes reflecting actual implementations have been made:
+      </p>
+      <ul>
+         <li>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.
+         </li>
+         <li>RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't
+            reflect actual use.
+         </li>
+         <li>The definition for the disposition type "inline" (<a href="#RFC2183" id="rfc.xref.RFC2183.6"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.1">Section 2.1</a>) has been re-added with a suggestion for its processing.
+         </li>
+         <li>This specification requires support for the extended parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.8"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
+         </li>
+      </ul>
+      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></h1>
+      <p id="rfc.section.B.p.1"> <a href="http://tools.ietf.org/html/rfc2183#section-2">Section 2</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.7"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The
+         majority of user agents does not implement these, thus they have been omitted from this specification.
+      </p>
+      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="alternatives" href="#alternatives">Alternative Approaches to Internationalization</a></h1>
+      <p id="rfc.section.C.p.1">By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.2"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) character encoding (see <a href="#RFC2616" id="rfc.xref.RFC2616.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>). For the "filename" parameter, this of course is an unacceptable restriction.
+      </p>
+      <p id="rfc.section.C.p.2">Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards
+         Track specifies exactly one solution (<a href="#RFC2231" id="rfc.xref.RFC2231.1"><cite title="MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations">[RFC2231]</cite></a>, clarified and profiled for HTTP in <a href="#RFC5987" id="rfc.xref.RFC5987.9"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>).
+      </p>
+      <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explains how they are inferior
+         to the RFC 5987 encoding used in this specification.
+      </p>
+      <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;<a id="alternatives.rfc2047" href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2>
+      <p id="rfc.section.C.1.p.1">RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters
+         - see <a href="http://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>:
+      </p>
+      <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5">
+         <p>An 'encoded-word' MUST NOT appear within a 'quoted-string'.</p>
+         <p>...</p>
+         <p>An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured
+            field body except within a 'comment' or 'phrase'.
+         </p>
+      </blockquote>
+      <p id="rfc.section.C.1.p.3">In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get
+         confused by it.
+      </p>
+      <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<a id="alternatives.percent" href="#alternatives.percent">Percent Encoding</a></h2>
+      <p id="rfc.section.C.2.p.1">Some user agents accept percent encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding
+         of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
+      </p>
+      <p id="rfc.section.C.2.p.2">In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence
+         to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually
+         expect.
+      </p>
+      <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a>&nbsp;<a id="alternatives.sniff" href="#alternatives.sniff">Encoding Sniffing</a></h2>
+      <p id="rfc.section.C.3.p.1">Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems
+         to be more likely to be the correct interpretation.
+      </p>
+      <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and furthermore risks misinterpreting the actual value.</p>
+      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="alternatives.implementations" href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2>
+      <p id="rfc.section.C.4.p.1">Unfortunately, as of February 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches
+         discussed above was implemented interoperably. Thus, this specification recommends the approach defined in RFC 5987, which
+         at least has the advantage of actually being specified properly.
+      </p>
+      <p id="rfc.section.C.4.p.2">The table below shows the implementation support for the various approaches:</p>
+      <div id="rfc.table.u.1">
+         <table class="tt full left" cellpadding="3" cellspacing="0">
+            <thead>
+               <tr>
+                  <th>User Agent</th>
+                  <th>RFC 2231/5987</th>
+                  <th>RFC 2047</th>
+                  <th>Percent Encoding</th>
+                  <th>Encoding Sniffing</th>
+               </tr>
+            </thead>
+            <tbody>
+               <tr>
+                  <td class="left">Chrome</td>
+                  <td class="left">yes</td>
+                  <td class="left">yes</td>
+                  <td class="left">yes</td>
+                  <td class="left">yes</td>
+               </tr>
+               <tr>
+                  <td class="left">Firefox</td>
+                  <td class="left">yes (*)</td>
+                  <td class="left">yes</td>
+                  <td class="left">no</td>
+                  <td class="left">yes</td>
+               </tr>
+               <tr>
+                  <td class="left">Internet Explorer</td>
+                  <td class="left">yes (**)</td>
+                  <td class="left">no</td>
+                  <td class="left">yes</td>
+                  <td class="left">no</td>
+               </tr>
+               <tr>
+                  <td class="left">Konqueror</td>
+                  <td class="left">yes</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+               </tr>
+               <tr>
+                  <td class="left">Opera</td>
+                  <td class="left">yes</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+               </tr>
+               <tr>
+                  <td class="left">Safari</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+                  <td class="left">no</td>
+                  <td class="left">yes</td>
+               </tr>
+            </tbody>
+         </table>
+      </div>
+      <p id="rfc.section.C.4.p.3">(*) Does not implement the fallback behavior to "filename" described in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>.
+      </p>
+      <p id="rfc.section.C.4.p.4">(**) Starting with IE9RC, but only implements UTF-8.</p>
+      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
+      <p id="rfc.section.D.p.1">Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http refer to &lt;<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html">http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html</a>&gt;.
+      </p>
+      <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;Since draft-reschke-rfc2183-in-http-00
+      </h2>
+      <p id="rfc.section.D.1.p.1">Adjust terminology ("header" -&gt; "header field"). Update rfc2231-in-http reference.</p>
+      <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a>&nbsp;Since draft-reschke-rfc2183-in-http-01
+      </h2>
+      <p id="rfc.section.D.2.p.1">Update rfc2231-in-http reference. Actually define the "filename" parameter. Add internationalization considerations. Add examples
+         using the RFC 5987 encoding. Add overview over other approaches, plus a table reporting implementation status. Add and resolve
+         issue "nodep2183". Add issues "asciivsiso", "deplboth", "quoted", and "registry".
+      </p>
+      <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;Since draft-reschke-rfc2183-in-http-02
+      </h2>
+      <p id="rfc.section.D.3.p.1">Add and close issue "docfallback". Close issues "asciivsiso", "deplboth", "quoted", and "registry".</p>
+      <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a>&nbsp;Since draft-reschke-rfc2183-in-http-03
+      </h2>
+      <p id="rfc.section.D.4.p.1">Updated to be a Working Draft of the IETF HTTPbis Working Group.</p>
+      <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a id="changes.since.00" href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></h2>
+      <p id="rfc.section.D.5.p.1">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/242">http://tools.ietf.org/wg/httpbis/trac/ticket/242</a>&gt;: "handling of unknown disposition types"
+         </li>
+      </ul>
+      <p id="rfc.section.D.5.p.2">Slightly updated the notes about the proposed fallback behavior.</p>
+      <h2 id="rfc.section.D.6"><a href="#rfc.section.D.6">D.6</a>&nbsp;<a id="changes.since.01" href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></h2>
+      <p id="rfc.section.D.6.p.1">Various editorial improvements.</p>
+      <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></h2>
+      <p id="rfc.section.D.7.p.1">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/244">http://tools.ietf.org/wg/httpbis/trac/ticket/244</a>&gt;: "state that repeating parameters are invalid"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/245">http://tools.ietf.org/wg/httpbis/trac/ticket/245</a>&gt;: "warn about %xx in filenames being misinterpreted"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/246">http://tools.ietf.org/wg/httpbis/trac/ticket/246</a>&gt;: "mention control chars when talking about postprecessing the filename parameter"
+         </li>
+      </ul>
+      <p id="rfc.section.D.7.p.2">Update <a href="#alternatives.implementations" title="Implementations (to be removed by RFC Editor before publication)">Appendix&nbsp;C.4</a>; Opera 10.63 RC implements the recommended fallback behavior.
+      </p>
+      <h2 id="rfc.section.D.8"><a href="#rfc.section.D.8">D.8</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></h2>
+      <p id="rfc.section.D.8.p.1">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/252">http://tools.ietf.org/wg/httpbis/trac/ticket/252</a>&gt;: "'modification-date' *is* implemented in Konq 4.5"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/253">http://tools.ietf.org/wg/httpbis/trac/ticket/253</a>&gt;: "clarify what LWS means for the Content-Disp grammar"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/258">http://tools.ietf.org/wg/httpbis/trac/ticket/258</a>&gt;: "Avoid passive voice in message requirements"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/263">http://tools.ietf.org/wg/httpbis/trac/ticket/263</a>&gt;: "text about historical percent-decoding unclear"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/264">http://tools.ietf.org/wg/httpbis/trac/ticket/264</a>&gt;: "add explanation of language tagging"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/265">http://tools.ietf.org/wg/httpbis/trac/ticket/265</a>&gt;: "Clarify that C-D spec does not apply to multipart upload"
+         </li>
+      </ul>
+      <h2 id="rfc.section.D.9"><a href="#rfc.section.D.9">D.9</a>&nbsp;<a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></h2>
+      <p id="rfc.section.D.9.p.1">Updated implementation information (Chrome 9 implements RFC 5987, IE 9 RC implements it for UTF-8 only).</p>
+      <p id="rfc.section.D.9.p.2">Clarify who requirements are on, add a section discussing conformance and handling of invalid field values in general.</p>
+      <p id="rfc.section.D.9.p.3">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/272">http://tools.ietf.org/wg/httpbis/trac/ticket/272</a>&gt;: "Path Separator Characters"
+         </li>
+      </ul>
+      <div id="changes.from.rfc2616">
+         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></h1>
+         <p id="rfc.section.A.p.1">Compared to <a href="https://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.10"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, the following normative changes reflecting actual implementations have been made:
+         </p>
+         <ul>
+            <li>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.
+            </li>
+            <li>RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't
+               reflect actual use.
+            </li>
+            <li>The definition for the disposition type "inline" (<a href="#RFC2183" id="rfc.xref.RFC2183.6"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.1">Section 2.1</a>) has been re-added with a suggestion for its processing.
+            </li>
+            <li>This specification requires support for the extended parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.8"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
+            </li>
+         </ul>
+      </div>
+      <div id="diffs.compared.to.rfc2183">
+         <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></h1>
+         <p id="rfc.section.B.p.1"><a href="https://tools.ietf.org/html/rfc2183#section-2">Section 2</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.7"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The
+            majority of user agents does not implement these, thus they have been omitted from this specification.
+         </p>
+      </div>
+      <div id="alternatives">
+         <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a href="#alternatives">Alternative Approaches to Internationalization</a></h1>
+         <p id="rfc.section.C.p.1">By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.2"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) character encoding (see <a href="#RFC2616" id="rfc.xref.RFC2616.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>). For the "filename" parameter, this of course is an unacceptable restriction.
+         </p>
+         <p id="rfc.section.C.p.2">Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards
+            Track specifies exactly one solution (<a href="#RFC2231" id="rfc.xref.RFC2231.1"><cite title="MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations">[RFC2231]</cite></a>, clarified and profiled for HTTP in <a href="#RFC5987" id="rfc.xref.RFC5987.9"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>).
+         </p>
+         <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explains how they are inferior
+            to the RFC 5987 encoding used in this specification.
+         </p>
+         <div id="alternatives.rfc2047">
+            <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;<a href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2>
+            <p id="rfc.section.C.1.p.1">RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters
+               - see <a href="https://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>:
+            </p>
+            <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5">
+               <p>An 'encoded-word' MUST NOT appear within a 'quoted-string'.</p>
+               <p>...</p>
+               <p>An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured
+                  field body except within a 'comment' or 'phrase'.
+               </p>
+            </blockquote>
+            <p id="rfc.section.C.1.p.3">In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get
+               confused by it.
+            </p>
+         </div>
+         <div id="alternatives.percent">
+            <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<a href="#alternatives.percent">Percent Encoding</a></h2>
+            <p id="rfc.section.C.2.p.1">Some user agents accept percent encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding
+               of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
+            </p>
+            <p id="rfc.section.C.2.p.2">In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence
+               to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually
+               expect.
+            </p>
+         </div>
+         <div id="alternatives.sniff">
+            <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a>&nbsp;<a href="#alternatives.sniff">Encoding Sniffing</a></h2>
+            <p id="rfc.section.C.3.p.1">Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems
+               to be more likely to be the correct interpretation.
+            </p>
+            <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and furthermore risks misinterpreting the actual value.</p>
+         </div>
+         <div id="alternatives.implementations">
+            <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2>
+            <p id="rfc.section.C.4.p.1">Unfortunately, as of February 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches
+               discussed above was implemented interoperably. Thus, this specification recommends the approach defined in RFC 5987, which
+               at least has the advantage of actually being specified properly.
+            </p>
+            <p id="rfc.section.C.4.p.2">The table below shows the implementation support for the various approaches:</p>
+            <div id="rfc.table.u.1">
+               <table class="tt full left" cellpadding="3" cellspacing="0">
+                  <thead>
+                     <tr>
+                        <th>User Agent</th>
+                        <th>RFC 2231/5987</th>
+                        <th>RFC 2047</th>
+                        <th>Percent Encoding</th>
+                        <th>Encoding Sniffing</th>
+                     </tr>
+                  </thead>
+                  <tbody>
+                     <tr>
+                        <td class="left">Chrome</td>
+                        <td class="left">yes</td>
+                        <td class="left">yes</td>
+                        <td class="left">yes</td>
+                        <td class="left">yes</td>
+                     </tr>
+                     <tr>
+                        <td class="left">Firefox</td>
+                        <td class="left">yes (*)</td>
+                        <td class="left">yes</td>
+                        <td class="left">no</td>
+                        <td class="left">yes</td>
+                     </tr>
+                     <tr>
+                        <td class="left">Internet Explorer</td>
+                        <td class="left">yes (**)</td>
+                        <td class="left">no</td>
+                        <td class="left">yes</td>
+                        <td class="left">no</td>
+                     </tr>
+                     <tr>
+                        <td class="left">Konqueror</td>
+                        <td class="left">yes</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                     </tr>
+                     <tr>
+                        <td class="left">Opera</td>
+                        <td class="left">yes</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                     </tr>
+                     <tr>
+                        <td class="left">Safari</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                        <td class="left">no</td>
+                        <td class="left">yes</td>
+                     </tr>
+                  </tbody>
+               </table>
+            </div>
+            <p id="rfc.section.C.4.p.3">(*) Does not implement the fallback behavior to "filename" described in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section&nbsp;4.3</a>.
+            </p>
+            <p id="rfc.section.C.4.p.4">(**) Starting with IE9RC, but only implements UTF-8.</p>
+         </div>
+      </div>
+      <div id="change.log">
+         <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
+         <p id="rfc.section.D.p.1">Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http refer to &lt;<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html">http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html</a>&gt;.
+         </p>
+         <div>
+            <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;Since draft-reschke-rfc2183-in-http-00
+            </h2>
+            <p id="rfc.section.D.1.p.1">Adjust terminology ("header" -&gt; "header field"). Update rfc2231-in-http reference.</p>
+         </div>
+         <div>
+            <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a>&nbsp;Since draft-reschke-rfc2183-in-http-01
+            </h2>
+            <p id="rfc.section.D.2.p.1">Update rfc2231-in-http reference. Actually define the "filename" parameter. Add internationalization considerations. Add examples
+               using the RFC 5987 encoding. Add overview over other approaches, plus a table reporting implementation status. Add and resolve
+               issue "nodep2183". Add issues "asciivsiso", "deplboth", "quoted", and "registry".
+            </p>
+         </div>
+         <div>
+            <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;Since draft-reschke-rfc2183-in-http-02
+            </h2>
+            <p id="rfc.section.D.3.p.1">Add and close issue "docfallback". Close issues "asciivsiso", "deplboth", "quoted", and "registry".</p>
+         </div>
+         <div>
+            <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a>&nbsp;Since draft-reschke-rfc2183-in-http-03
+            </h2>
+            <p id="rfc.section.D.4.p.1">Updated to be a Working Draft of the IETF HTTPbis Working Group.</p>
+         </div>
+         <div id="changes.since.00">
+            <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></h2>
+            <p id="rfc.section.D.5.p.1">Closed issues: </p>
+            <ul>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/242">http://tools.ietf.org/wg/httpbis/trac/ticket/242</a>&gt;: "handling of unknown disposition types"
+               </li>
+            </ul>
+            <p id="rfc.section.D.5.p.2">Slightly updated the notes about the proposed fallback behavior.</p>
+         </div>
+         <div id="changes.since.01">
+            <h2 id="rfc.section.D.6"><a href="#rfc.section.D.6">D.6</a>&nbsp;<a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></h2>
+            <p id="rfc.section.D.6.p.1">Various editorial improvements.</p>
+         </div>
+         <div id="changes.since.02">
+            <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></h2>
+            <p id="rfc.section.D.7.p.1">Closed issues: </p>
+            <ul>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/244">http://tools.ietf.org/wg/httpbis/trac/ticket/244</a>&gt;: "state that repeating parameters are invalid"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/245">http://tools.ietf.org/wg/httpbis/trac/ticket/245</a>&gt;: "warn about %xx in filenames being misinterpreted"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/246">http://tools.ietf.org/wg/httpbis/trac/ticket/246</a>&gt;: "mention control chars when talking about postprecessing the filename parameter"
+               </li>
+            </ul>
+            <p id="rfc.section.D.7.p.2">Update <a href="#alternatives.implementations" title="Implementations (to be removed by RFC Editor before publication)">Appendix&nbsp;C.4</a>; Opera 10.63 RC implements the recommended fallback behavior.
+            </p>
+         </div>
+         <div id="changes.since.03">
+            <h2 id="rfc.section.D.8"><a href="#rfc.section.D.8">D.8</a>&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></h2>
+            <p id="rfc.section.D.8.p.1">Closed issues: </p>
+            <ul>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/252">http://tools.ietf.org/wg/httpbis/trac/ticket/252</a>&gt;: "'modification-date' *is* implemented in Konq 4.5"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/253">http://tools.ietf.org/wg/httpbis/trac/ticket/253</a>&gt;: "clarify what LWS means for the Content-Disp grammar"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/258">http://tools.ietf.org/wg/httpbis/trac/ticket/258</a>&gt;: "Avoid passive voice in message requirements"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/263">http://tools.ietf.org/wg/httpbis/trac/ticket/263</a>&gt;: "text about historical percent-decoding unclear"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/264">http://tools.ietf.org/wg/httpbis/trac/ticket/264</a>&gt;: "add explanation of language tagging"
+               </li>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/265">http://tools.ietf.org/wg/httpbis/trac/ticket/265</a>&gt;: "Clarify that C-D spec does not apply to multipart upload"
+               </li>
+            </ul>
+         </div>
+         <div id="changes.since.04">
+            <h2 id="rfc.section.D.9"><a href="#rfc.section.D.9">D.9</a>&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></h2>
+            <p id="rfc.section.D.9.p.1">Updated implementation information (Chrome 9 implements RFC 5987, IE 9 RC implements it for UTF-8 only).</p>
+            <p id="rfc.section.D.9.p.2">Clarify who requirements are on, add a section discussing conformance and handling of invalid field values in general.</p>
+            <p id="rfc.section.D.9.p.3">Closed issues: </p>
+            <ul>
+               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/272">http://tools.ietf.org/wg/httpbis/trac/ticket/272</a>&gt;: "Path Separator Characters"
+               </li>
+            </ul>
+         </div>
+      </div>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
       <p class="noprint"><a href="#rfc.index.C">C</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.R">R</a>
 …
          </ul>
       </div>
+      <div class="avoidbreak">
+         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
+         <p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p>
+      </div>
    </body>
 </html>

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 2726 for draft-ietf-httpbis-content-disp/05

Legend:

draft-ietf-httpbis-content-disp/05/draft-ietf-httpbis-content-disp.html

Download in other formats: