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

Timestamp:

Dec 1, 2010, 4:07:53 AM (9 years ago)

Author:

julian.reschke@…

Message:

bump up document dates, update to latest version of rfc2629.xslt

Location:

draft-ietf-httpbis-content-disp/latest

Files:

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

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

@@ -232 +232 @@
   margin-left: 0em;
 }
-ul.ind {
+ul.ind, ul.ind ul {
   list-style: none;
   margin-left: 1.5em;
@@ -356 +356 @@
   } 
   @top-right {
-       content: "November 2010"; 
+       content: "December 2010"; 
   } 
   @top-center {
@@ -400 +400 @@
       <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.531, 2010-10-31 21:50:52, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <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/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <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-11-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-12-01">
       <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.">
@@ -422 +422 @@
                <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
                </td>
-               <td class="right">November 12, 2010</td>
+               <td class="right">December 1, 2010</td>
             </tr>
             <tr>
@@ -429 +429 @@
             </tr>
             <tr>
-               <td class="left">Expires: May 16, 2011</td>
+               <td class="left">Expires: June 4, 2011</td>
                <td class="right"></td>
             </tr>
@@ -458 +458 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on May 16, 2011.</p>
+      <p>This Internet-Draft will expire on June 4, 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>
@@ -656 +656 @@
                      filename="EURO rates";
                      filename*=utf-8''<b>%e2%82%ac</b>%20rates
-</pre>  <p>Note: as of November 2010, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after
+</pre>  <p>Note: as of December 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.
@@ -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>
       <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 November 2010, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches
+      <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
          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.

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

@@ -42 +42 @@
   </author>
 
-  <date month="November" year="2010"/>
+  <date month="December" year="2010"/>
   <workgroup>HTTPbis Working Group</workgroup>
   
@@ -327 +327 @@
 </artwork>
 <postamble>
-  Note: as of November 2010, those user agents that do not support the RFC 5987
+  Note: as of December 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
@@ -741 +741 @@
 <section title="Implementations (to be removed by RFC Editor before publication)" anchor="alternatives.implementations">
 <t>
-  Unfortunately, as of November 2010, neither the encoding defined in RFCs 2231
+  Unfortunately, as of December 2010, 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