Changeset 970 for draft-ietf-httpbis/latest/p4-conditional.html

Timestamp:

31/07/10 08:54:31 (11 years ago)

Author:

julian.reschke@…

Message:

regen HTML

File:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (8 diffs)

draft-ietf-httpbis/latest/p4-conditional.html

@@ -400 +400 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 31, 2011</td>
+               <td class="left">Expires: February 1, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 30, 2010</td>
+               <td class="right">July 31, 2010</td>
             </tr>
          </tbody>
@@ -509 +509 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in January 31, 2011.</p>
+      <p>This Internet-Draft will expire in February 1, 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>
@@ -881 +881 @@
       </p>
       <ul class="empty">
-         <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information
+         <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information
             as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
             assumptions about the validators they receive.
@@ -989 +989 @@
          </li>
          <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
-            the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.
-            The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the
-            client and server. This includes the possibility of race conditions if the document has changed between the time it was first
-            requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the
-            If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different
-            time bases between client and server are at best approximate due to network latency.
+            the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized
+            clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes
+            the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since
+            date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived
+            from the client's clock without correction to the server's clock. Corrections for different time bases between client and
+            server are at best approximate due to network latency.
          </li>
       </ul>
@@ -1086 +1086 @@
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
-      <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
+      <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
       </p>
       <div id="rfc.table.1">
@@ -1115 +1115 @@
       </div>
       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
-      <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
+      <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
       </p>
       <div id="rfc.table.2">