Code change:
representation and the date is a strong validator in the sense defined by lastmod.comparison. <del> A server that evaluates an If-Range precondition MUST use the strong comparison function when comparing entity-tags (entity.tag.comparison) and MUST evaluate the condition as false if an </del> <ins> A server that receives an If-Range header field on a Range request MUST evaluate the condition as per evaluation prior to performing the method. </ins> <del> validator is provided that is not a strong validator in the sense defined by lastmod.comparison.  A valid </del> <ins> To evaluate a received If-Range header field containing an </ins> <del> can be distinguished from a valid </del> <ins> : </ins> <del> by examining the first three characters for a DQUOTE. </del> <ins> To evaluate a received If-Range header field containing an : </ins> <del> If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server SHOULD process the </del> <ins> A recipient of an If-Range header field MUST ignore the </ins> <del> header field as requested.  If the validator does not match, the server MUST ignore the </del> <ins> header field if the If-Range condition evaluates to false. Otherwise, the recipient SHOULD process the </ins> <del> header field.  Note that this comparison by exact match, including when the validator is an </del> <ins> header field as requested. Note that the If-Range comparison by exact match, including when the validator is an </ins> , differs from the "earlier than or equal to" comparison used when evaluating an

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.