Ignore:
Timestamp:
Mar 3, 2010, 8:14:02 AM (10 years ago)
Author:
julian.reschke@…
Message:

assign stable anchors to all <cref> elements

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.xml

    r766 r767  
    506506  single Age header field (<xref target="header.age" />) in the response with a value equal to the stored response's
    507507  current_age; see <xref target="age.calculations" />.
    508   <cref>DISCUSS: this currently includes successfully validated responses.</cref>
     508  <cref anchor="DISCUSS-includes-validated">this currently includes successfully validated responses.</cref>
    509509</t>
    510510<t>
     
    545545  assign an explicit expiration time in the past. This means that the response is always
    546546  stale, so that caches should validate it before using it for subsequent requests.
    547   <cref>This wording may cause confusion, because the response may still be served stale.</cref>
     547  <cref anchor="TODO-response-stale">This wording may cause confusion, because the response may still be served stale.</cref>
    548548</t>
    549549<t>
     
    573573</t>
    574574<t>
    575   <cref>ISSUE: there are not requirements directly applying to cache-request-directives and
     575  <cref anchor="ISSUE-no-req-for-directives">there are not requirements directly applying to cache-request-directives and
    576576  freshness.</cref>
    577577</t>
     
    619619</t>
    620620<t>
    621   <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref>
     621  <cref anchor="REVIEW-query-string-heuristics">took away HTTP/1.0 query string heuristic uncacheability.</cref>
    622622</t>
    623623</section>
     
    763763  of the stored responses nominated in the conditional request is
    764764  suitable. Instead, the full response is used both to satisfy the
    765   request and replace the stored response. <cref>Should there be a requirement here?</cref>
     765  request and replace the stored response. <cref anchor="TODO-req-missing">Should there be a requirement here?</cref>
    766766</t>
    767767<t>
     
    794794</t>
    795795<t>
    796   <cref>TODO: "host part" needs to be specified better.</cref>
     796  <cref anchor="TODO-def-host-part">"host part" needs to be specified better.</cref>
    797797</t>
    798798<t>
     
    811811</t>
    812812<t>
    813   <cref>TODO: specify that only successful (2xx, 3xx?) responses invalidate.</cref>
     813  <cref anchor="TODO-spec-success-invalidate">specify that only successful (2xx, 3xx?) responses invalidate.</cref>
    814814</t>
    815815</section>
     
    827827  selecting request-headers in the first request can be transformed to the selecting
    828828  request-headers in the second request by adding or removing linear white space
    829   <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
     829  <cref anchor="TODO-missing-ref">[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    830830  combining multiple message-header fields with the same field name following the rules
    831831  about header fields in &header-fields;.
     
    857857<t>
    858858  If the new response contains an ETag, it identifies the stored 
    859   response to use. <cref>may need language about Content-Location 
    860   here</cref><cref>cover case where INM with multiple etags was sent</cref>
     859  response to use. <cref anchor="TODO-mention-CL">may need language about Content-Location 
     860  here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref>
    861861</t>
    862862<t>
     
    882882</t>
    883883<t>
    884   The updated response can [[<cref>requirement?</cref>]] be used to replace the 
     884  The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the 
    885885  stored response in cache. In the case of a 206 response, the combined 
    886886  entity-body &MAY; be stored.
    887887</t>
    888888<t>
    889   <cref>ISSUE: discuss how to handle HEAD updates</cref>
     889  <cref anchor="ISSUE-how-head">discuss how to handle HEAD updates</cref>
    890890</t>
    891891</section>
     
    10371037      then the client is willing to accept a response that has exceeded its expiration
    10381038      time by no more than the specified number of seconds. If no value is assigned to
    1039       max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t>
     1039      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>
    10401040  </list>
    10411041</t>
     
    20322032  delimiting); it was important to straighten out exactly how message lengths are computed.
    20332033  (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)
    2034   <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
     2034  <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>
    20352035</t>
    20362036<t>
    20372037  Proxies should be able to add Content-Length when appropriate.
    2038   <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
     2038  <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>
    20392039</t>
    20402040<t
Note: See TracChangeset for help on using the changeset viewer.