Changeset 1095 for draft-ietf-httpbis-content-disp
- Timestamp:
- Dec 1, 2010, 4:07:53 AM (9 years ago)
- Location:
- draft-ietf-httpbis-content-disp/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html
r1085 r1095 232 232 margin-left: 0em; 233 233 } 234 ul.ind {234 ul.ind, ul.ind ul { 235 235 list-style: none; 236 236 margin-left: 1.5em; … … 356 356 } 357 357 @top-right { 358 content: " November 2010";358 content: "December 2010"; 359 359 } 360 360 @top-center { … … 400 400 <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C"> 401 401 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> 402 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.53 1, 2010-10-31 21:50:52, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">402 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.536, 2010-11-29 12:56:12, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 403 403 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-content-disp-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-1 1-12">406 <meta name="dct.issued" scheme="ISO8601" content="2010-12-01"> 407 407 <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."> 408 408 <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."> … … 422 422 <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) 423 423 </td> 424 <td class="right"> November 12, 2010</td>424 <td class="right">December 1, 2010</td> 425 425 </tr> 426 426 <tr> … … 429 429 </tr> 430 430 <tr> 431 <td class="left">Expires: May 16, 2011</td>431 <td class="left">Expires: June 4, 2011</td> 432 432 <td class="right"></td> 433 433 </tr> … … 458 458 in progress”. 459 459 </p> 460 <p>This Internet-Draft will expire on May 16, 2011.</p>460 <p>This Internet-Draft will expire on June 4, 2011.</p> 461 461 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 462 462 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 656 656 filename="EURO rates"; 657 657 filename*=utf-8''<b>%e2%82%ac</b>%20rates 658 </pre> <p>Note: as of November 2010, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after658 </pre> <p>Note: as of December 2010, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after 659 659 "filename". Unfortunately, some user agents that do support RFC 5987 do pick the "filename" rather than the "filename*" parameter 660 660 when it occurs first; it is expected that this situation is going to improve soon. … … 823 823 <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> 824 824 <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <a id="alternatives.implementations" href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2> 825 <p id="rfc.section.C.4.p.1">Unfortunately, as of November 2010, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches825 <p id="rfc.section.C.4.p.1">Unfortunately, as of December 2010, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches 826 826 discussed above was implemented interoperably. Thus, this specification recommends the approach defined in RFC 5987, which 827 827 at least has the advantage of actually being specified properly. -
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1085 r1095 42 42 </author> 43 43 44 <date month=" November" year="2010"/>44 <date month="December" year="2010"/> 45 45 <workgroup>HTTPbis Working Group</workgroup> 46 46 … … 327 327 </artwork> 328 328 <postamble> 329 Note: as of November 2010, those user agents that do not support the RFC 5987329 Note: as of December 2010, those user agents that do not support the RFC 5987 330 330 encoding ignore "filename*" when it occurs after "filename". Unfortunately, 331 331 some user agents that do support RFC 5987 do pick the "filename" rather … … 741 741 <section title="Implementations (to be removed by RFC Editor before publication)" anchor="alternatives.implementations"> 742 742 <t> 743 Unfortunately, as of November 2010, neither the encoding defined in RFCs 2231743 Unfortunately, as of December 2010, neither the encoding defined in RFCs 2231 744 744 and 5987, nor any of the alternate approaches discussed above was 745 745 implemented interoperably. Thus, this specification recommends the approach
Note: See TracChangeset
for help on using the changeset viewer.