Changeset 766 for draft-ietf-httpbis/latest

Timestamp:

Mar 3, 2010, 1:19:25 AM (10 years ago)

Author:

julian.reschke@…

Message:

Simplify discussion of history lists (see #197)

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -402 +402 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-03-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-03-03">
       <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. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -428 +428 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 2, 2010</td>
+               <td class="left">Expires: September 4, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 1, 2010</td>
+               <td class="right">March 3, 2010</td>
             </tr>
          </tbody>
@@ -519 +519 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
       </p>
-      <p>This Internet-Draft will expire in September 2, 2010.</p>
+      <p>This Internet-Draft will expire in September 4, 2010.</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>
@@ -1377 +1377 @@
          retrieved earlier in a session.
       </p>
-      <p id="rfc.section.4.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a correct view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the
-         user saw at the time when the resource was retrieved.
-      </p>
-      <p id="rfc.section.4.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history
-         documents.
-      </p>
-      <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.</p>
-      <div class="note" id="rfc.section.4.p.5"> 
-         <p> <b>Note:</b> If history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
-            to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider
-            it important that users not be presented with error messages or warning messages when they use navigation controls (such as
-            BACK) to view previously fetched resources. Even though sometimes such resources ought not be cached, or ought to expire quickly,
-            user interface considerations may force service authors to resort to other means of preventing caching (e.g., "once-only"
-            URLs) in order not to suffer the effects of improperly functioning history mechanisms.
-         </p> 
-      </div>
+      <p id="rfc.section.4.p.2">The freshness model (<a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
+         it has expired.
+      </p>
+      <p id="rfc.section.4.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives
+         (e.g., Cache-Control: no-store).
+      </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2>
@@ -1754 +1744 @@
       </ul>
       <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a>&nbsp;<a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p6-cache-08</a></h2>
-      <p id="rfc.section.C.10.p.1">Affected issues: </p>
+      <p id="rfc.section.C.10.p.1">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/197">http://tools.ietf.org/wg/httpbis/trac/ticket/197</a>&gt;: "Effect of CC directives on history lists"
+         </li>
+      </ul>
+      <p id="rfc.section.C.10.p.2">Affected issues: </p>
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/199">http://tools.ietf.org/wg/httpbis/trac/ticket/199</a>&gt;: Status codes and caching

draft-ietf-httpbis/latest/p6-cache.xml

@@ -1545 +1545 @@
 </t>
 <t>
-  History mechanisms and caches are different. In particular history mechanisms
-  &SHOULD-NOT; try to show a correct view of the current state of a resource. Rather, a
-  history mechanism is meant to show exactly what the user saw at the time when the resource
-  was retrieved.
-</t>
-<t>
-  By default, an expiration time does not apply to history mechanisms. If the entity is still
-  in storage, a history mechanism &SHOULD; display it even if the entity has expired,
-  unless the user has specifically configured the agent to refresh expired history documents.
-</t>
-<t>
-  This is not to be construed to prohibit the history mechanism from telling the user that a
-  view might be stale.
-</t>
-<x:note>
+  The freshness model (<xref target="expiration.model"/>) does not necessarily apply to history mechanisms. I.e., 
+  a history mechanism can display a previous representation even if it has expired.
+</t>
   <t>
-    <x:h>Note:</x:h> If history list mechanisms unnecessarily prevent users from viewing
-    stale resources, this will tend to force service authors to avoid using HTTP expiration
-    controls and cache controls when they would otherwise like to. Service authors may
-    consider it important that users not be presented with error messages or warning
-    messages when they use navigation controls (such as BACK) to view previously fetched
-    resources. Even though sometimes such resources ought not be cached, or ought to expire
-    quickly, user interface considerations may force service authors to resort to other
-    means of preventing caching (e.g., "once-only" URLs) in order not to suffer the effects
-    of improperly functioning history mechanisms.
+  This does not prohibit the history mechanism from telling the user that a
+  view might be stale, or from honoring cache directives (e.g., Cache-Control: no-store).
   </t>
-</x:note>
 </section>
 
@@ -2344 +2324 @@
 <section anchor="changes.since.08" title="Since draft-ietf-httpbis-p6-cache-08">
 <t>
+  Closed issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/197" />:
+      "Effect of CC directives on history lists"
+    </t>
+  </list>
+</t>
+<t>
   Affected issues:
   <list style="symbols">