Ignore:
Timestamp:
11/02/13 06:10:25 (7 years ago)
Author:
mnot@…
Message:

Tidy up discussion of heuristic freshness, with follow-on effects in the
definition of 'public', the storage algorithm, and considerations for new
status codes. Addresses #223

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2177 r2179  
    43054305</t>
    43064306<t>
    4307    A definition for a new status code ought to explain the request
     4307   The definition of a new status code ought to explain the request
    43084308   conditions that would cause a response containing that status code (e.g.,
    43094309   combinations of request header fields and/or method(s)) along with any
     
    43134313</t>
    43144314<t>
    4315    A response that can transfer a payload ought to specify expected cache
    4316    behavior (e.g., cacheability and freshness criteria, as described in
    4317    &caching;) and whether the payload has any implied association with an
    4318    identified resource (<xref target="identifying.payload"/>).
     4315   The definition of a new status code ought to specify whether or not it is
     4316   cacheable. Note that all status codes can be cached if the response they
     4317   occur in has explicit freshness information; however, status codes that are
     4318   defined as being cacheable are allowed to be cached without explicit
     4319   freshness information. Likewise, the definition of a status code can place
     4320   constraints upon cache behaviour. See &caching; for more information.
     4321</t>
     4322<t>   
     4323   Finally, the definition of a new status code ought to indicate whether the
     4324   payload has any implied association with an identified resource (<xref
     4325   target="identifying.payload"/>).
    43194326</t>
    43204327</section>
Note: See TracChangeset for help on using the changeset viewer.