Changeset 1016 for draft-ietf-httpbis-content-disp

Timestamp:

Sep 21, 2010, 12:54:16 AM (9 years ago)

Author:

julian.reschke@…

Message:

editorial improvements, suggested by MNot

Location:

draft-ietf-httpbis-content-disp/latest

Files:

• draft-ietf-httpbis-content-disp.html (modified) (8 diffs)
• draft-ietf-httpbis-content-disp.xml (modified) (4 diffs)

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

@@ -401 +401 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-content-disp-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-09-16">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-09-21">
       <meta name="dct.abstract" content="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.">
       <meta name="description" content="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.">
@@ -419 +419 @@
                <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
                </td>
-               <td class="right">September 16, 2010</td>
+               <td class="right">September 21, 2010</td>
             </tr>
             <tr>
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 20, 2011</td>
+               <td class="left">Expires: March 25, 2011</td>
                <td class="right"></td>
             </tr>
@@ -455 +455 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 20, 2011.</p>
+      <p>This Internet-Draft will expire on March 25, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -534 +534 @@
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.field.definition" href="#header.field.definition">Header Field Definition</a></h1>
       <p id="rfc.section.3.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.
+         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.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Grammar
@@ -561 +561 @@
       </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><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="disposition.type" href="#disposition.type">Disposition Type</a></h2>
-      <p id="rfc.section.3.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should not display the
-         response, but directly enter a "save as..." dialog.
+      <p id="rfc.section.3.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.3.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p>
@@ -591 +591 @@
          <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 later on the file is opened locally (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.
+               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>
@@ -668 +668 @@
       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;Acknowledgements
       </h1>
-      <p id="rfc.section.8.p.1">Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, and Henrik Nordstrom for their valuable feedback.</p>
+      <p id="rfc.section.8.p.1">Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for their
+         valuable feedback.
+      </p>
       <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
       </h1>

draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml

@@ -117 +117 @@
   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 attach additional metadata, such as the filename to use when saving the
+  response payload locally.
 </t>
 
@@ -154 +155 @@
 <section title="Disposition Type" anchor="disposition.type">
 <t>
-  If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should not display the response,
-  but directly enter a "save as..." dialog.
-</t>
-<t>
-  On the other hand, if it matches "inline" (case-insensitively), this implies default processing.
-</t>
-<t>
-  Unknown or unhandled disposition types &SHOULD; be handled the same way as "attachment"
-  (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
+  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).
+</t>
+<t>
+  On the other hand, if it matches "inline" (case-insensitively), this implies
+  default processing.
+</t>
+<t>
+  Unknown or unhandled disposition types &SHOULD; be handled the same way as
+  "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
 </t>
 </section>
@@ -207 +210 @@
       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 later on the file is opened locally
+      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
@@ -358 +361 @@
 <t>
   Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen,
-  and Henrik Nordstrom for their valuable feedback.
+  Henrik Nordstrom, and Mark Nottingham for their valuable feedback.
 </t>
 </section>