Relax 60-second for LM strong compare

draft-ietf-httpbis-semantics-latest.xml

@@ -3953,8 +3953,14 @@ Upgrade: websocket
        representation, and</li>
    <li>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
        time when the origin server sent the original response, and</li>
-   <li>The presented Last-Modified time is at least 60 seconds before
-       the Date value.</li>
+   <li><ul>
+      <li>The presented Last-Modified time is at least one second before the Date
+      value, and the client has reason to believe that they were generated by the
+      same clock, or</li>
+      <li>there is enough difference between the presented
+      Last-Modified time and Date value to make clock synchronisation issues
+      unlikely, in the judgement of the client.</li>
+   </ul></li>
 </ul>
 <t>
    or
@@ -3964,19 +3970,25 @@ Upgrade: websocket
        validator stored in its cache entry for the representation, and</li>
    <li>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
        time when the origin server sent the original response, and</li>
-   <li>The presented Last-Modified time is at least 60 seconds before
-       the Date value.</li>
+   <li><ul>
+      <li>The presented Last-Modified time is at least one second before the Date
+      value, and the cache has reason to believe that they were generated by the
+      same clock, or</li>
+      <li>there is enough difference between the presented
+      Last-Modified time and Date value to make clock synchronisation issues
+      unlikely, in the judgement of the cache.</li>
+   </ul></li>
 </ul>
 <t>
    This method relies on the fact that if two different responses were
    sent by the origin server during the same second, but both had the
    same Last-Modified time, then at least one of those responses would
-   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
-   arbitrary 60-second limit guards against the possibility that the Date and
+   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. Previous
+   revisions of this specification imposed an
+   arbitrary 60-second limit to guard against the possibility that the Date and
    Last-Modified values are generated from different clocks or at somewhat
-   different times during the preparation of the response. An
-   implementation &MAY; use a value larger than 60 seconds, if it is
-   believed that 60 seconds is too short.
+   different times during the preparation of the response. This specification
+   has relaxed that to allow reasonable discretion.
 </t>
 </section>
 </section>
@@ -13215,6 +13227,10 @@ transfer-coding = &lt;transfer-coding, see <xref target="Messaging" x:fmt="," x:
    concept of modification time.
    (<xref target="field.if-unmodified-since"/>)
 </t>
+<t>
+   Relaxed the arbitrary 60-second limit in determining whether
+   a Last-Modified header field value is a strong validator
+   (<xref target="lastmod.comparison"/>)
 </section>
 
 <section title="Changes from RFC 7233" anchor="changes.from.rfc.7233">
@@ -13515,6 +13531,7 @@ transfer-coding = &lt;transfer-coding, see <xref target="Messaging" x:fmt="," x:
   <li>In <xref target="intro.evolution"/>, reference <xref target="HTTP09"/> (<eref target="https://github.com/httpwg/http-core/issues/497"/>)</li>
   <li>In <xref target="status.1xx"/>, align language about bodies and trailers with 204 and 304 (<eref target="https://github.com/httpwg/http-core/issues/503"/>)</li>
   <li>In <xref target="field.name.registration"/>, note that this document updates <xref target="RFC3864"/> (<eref target="https://github.com/httpwg/http-core/issues/515"/>)</li>
+  <li>In <xref target="lastmod.comparison"/>, relax arbitrary 60-second comparison limit (<eref target="https://github.com/httpwg/http-core/issues/510"/>)</li>
 </ul>
 </section>
 </section>