Changeset 767 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

03/03/10 16:14:02 (11 years ago)

Author:

julian.reschke@…

Message:

assign stable anchors to all <cref> elements

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (12 diffs)

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

@@ -506 +506 @@
   single Age header field (<xref target="header.age" />) in the response with a value equal to the stored response's
   current_age; see <xref target="age.calculations" />. 
-  <cref>DISCUSS: this currently includes successfully validated responses.</cref>
+  <cref anchor="DISCUSS-includes-validated">this currently includes successfully validated responses.</cref>
 </t>
 <t>
@@ -545 +545 @@
   assign an explicit expiration time in the past. This means that the response is always
   stale, so that caches should validate it before using it for subsequent requests.
-  <cref>This wording may cause confusion, because the response may still be served stale.</cref>
+  <cref anchor="TODO-response-stale">This wording may cause confusion, because the response may still be served stale.</cref>
 </t>
 <t>
@@ -573 +573 @@
 </t>
 <t>
-  <cref>ISSUE: there are not requirements directly applying to cache-request-directives and
+  <cref anchor="ISSUE-no-req-for-directives">there are not requirements directly applying to cache-request-directives and
   freshness.</cref>
 </t>
@@ -619 +619 @@
 </t>
 <t>
-  <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref>
+  <cref anchor="REVIEW-query-string-heuristics">took away HTTP/1.0 query string heuristic uncacheability.</cref>
 </t>
 </section>
@@ -763 +763 @@
   of the stored responses nominated in the conditional request is
   suitable. Instead, the full response is used both to satisfy the
-  request and replace the stored response. <cref>Should there be a requirement here?</cref>
+  request and replace the stored response. <cref anchor="TODO-req-missing">Should there be a requirement here?</cref>
 </t>
 <t>
@@ -794 +794 @@
 </t>
 <t>
-  <cref>TODO: "host part" needs to be specified better.</cref>
+  <cref anchor="TODO-def-host-part">"host part" needs to be specified better.</cref>
 </t>
 <t>
@@ -811 +811 @@
 </t>
 <t>
-  <cref>TODO: specify that only successful (2xx, 3xx?) responses invalidate.</cref>
+  <cref anchor="TODO-spec-success-invalidate">specify that only successful (2xx, 3xx?) responses invalidate.</cref>
 </t>
 </section>
@@ -827 +827 @@
   selecting request-headers in the first request can be transformed to the selecting
   request-headers in the second request by adding or removing linear white space
-  <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
+  <cref anchor="TODO-missing-ref">[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
   combining multiple message-header fields with the same field name following the rules
   about header fields in &header-fields;.
@@ -857 +857 @@
 <t>
   If the new response contains an ETag, it identifies the stored  
-  response to use. <cref>may need language about Content-Location  
-  here</cref><cref>cover case where INM with multiple etags was sent</cref>
+  response to use. <cref anchor="TODO-mention-CL">may need language about Content-Location  
+  here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref>
 </t>
 <t>
@@ -882 +882 @@
 </t>
 <t>
-  The updated response can [[<cref>requirement?</cref>]] be used to replace the  
+  The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the  
   stored response in cache. In the case of a 206 response, the combined  
   entity-body &MAY; be stored.
 </t>
 <t>
-  <cref>ISSUE: discuss how to handle HEAD updates</cref>
+  <cref anchor="ISSUE-how-head">discuss how to handle HEAD updates</cref>
 </t>
 </section>
@@ -1037 +1037 @@
       then the client is willing to accept a response that has exceeded its expiration
       time by no more than the specified number of seconds. If no value is assigned to
-      max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t>
+      max-stale, then the client is willing to accept a stale response of any age. <cref anchor="TODO-staleness" source="mnot">of any staleness?</cref></t>
   </list>
 </t>
@@ -2032 +2032 @@
   delimiting); it was important to straighten out exactly how message lengths are computed.
   (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)
-  <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
+  <cref anchor="TODO-nonmod" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
 </t>
 <t>
   Proxies should be able to add Content-Length when appropriate.
-  <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
+  <cref anchor="TODO-nonmod2" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
 </t>
 <t