Changeset 996

Timestamp:

10/09/10 15:56:19 (12 years ago)

Author:

julian.reschke@…

Message:

update implementation notes

Location:

draft-ietf-httpbis-content-disp/latest

Files:

• draft-ietf-httpbis-content-disp.html (modified) (7 diffs)
• draft-ietf-httpbis-content-disp.xml (modified) (6 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-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-09-10">
       <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 9, 2010</td>
+               <td class="right">September 10, 2010</td>
             </tr>
             <tr>
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 13, 2011</td>
+               <td class="left">Expires: March 14, 2011</td>
                <td class="right"></td>
             </tr>
@@ -455 +455 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 13, 2011.</p>
+      <p>This Internet-Draft will expire on March 14, 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>
@@ -624 +624 @@
       <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 August 2010, many user agents unfortunately did not properly handle unexpected parameters, and some that implement
-         RFC 5987 did not pick the extended parameter when both were present.
+</pre>  <p>Note: as of September 2010, 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.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="i18n" href="#i18n">Internationalization Considerations</a></h1>
@@ -789 +790 @@
       <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</a></h2>
-      <p id="rfc.section.C.4.p.1">Unfortunately, as of August 2010, neither the encoding defined in RFCs 2231 and 5789, nor any of the alternate approaches
+      <p id="rfc.section.C.4.p.1">Unfortunately, as of September 2010, neither the encoding defined in RFCs 2231 and 5789, 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.
@@ -876 +877 @@
          </li>
       </ul>
+      <p id="rfc.section.D.5.p.2">Slightly updated the notes about the proposed fallback behavior.</p>
       <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> 

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

@@ -275 +275 @@
 </postamble>
 </figure>
-
-
 <figure>
 <preamble>
@@ -287 +285 @@
 </artwork>
 <postamble>
-  Note: as of August 2010, many user agents unfortunately did not properly handle
-  unexpected parameters, and some that implement RFC 5987 did not pick
-  the extended parameter when both were present. 
+  Note: as of September 2010, 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.
 </postamble>
 </figure>
@@ -689 +689 @@
 
 <section title="Implementations" anchor="alternatives.implementations">
-
-<t>
-  Unfortunately, as of August 2010, neither the encoding defined in RFCs 2231
+<t>
+  Unfortunately, as of September 2010, neither the encoding defined in RFCs 2231
   and 5789, nor any of the alternate approaches discussed above was
   implemented interoperably. Thus, this specification recommends the approach
@@ -702 +701 @@
   of actual UAs in a RFC? Up to the IESG to decide...</cref>  
 </t>
-
-
 <texttable align="left">
   <ttcol>User Agent</ttcol>
@@ -748 +745 @@
   
   <postamble>
-  (*) Does
-  not implement the fallback behavior to "filename" described in 
+  (*) Does not implement the fallback behavior to "filename" described in 
   <xref target="disposition.parameter.filename"/>.
-  
   </postamble>
 
@@ -807 +802 @@
   </list>
 </t>
+<t>
+  Slightly updated the notes about the proposed fallback behavior.
+</t>
 </section>
 </section>