update" problem: one client accidentally overwriting the work of another client that has been acting in parallel. <del> Conditional request preconditions are based on the state of the </del> <ins> 13.1. Preconditions are usually defined with respect to a state of the </ins> target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that <del> set).  A resource might have multiple current representations, each with its own observable state.  The conditional request mechanisms assume that the mapping of requests to a </del> <ins> set).  If a resource has multiple current representations, each with its own observable state, a precondition will assume that the mapping of each request to a (representations) is consistent over time.  Regardless, if the mapping is inconsistent or the server is unable to select an appropriate representation, then no harm will result when the precondition evaluates to false. Each precondition defined below consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (response.validator).  Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client.  The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in evaluation. Other preconditions, defined by other specifications as extension fields, might place conditions on all recipients, on the state of the target resource in general, or on a group of resources.  For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (RFC4918). </ins> <del> (representations) will be consistent over time if the server intends to take advantage of conditionals.  Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false. </del> <ins> Extensibility of preconditions is only possible when the precondition can be safely ignored if unknown (like </ins> <del> 13.1. The request header fields below allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false.  Each precondition defined by this specification consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (response.validator).  Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client.  The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in evaluation. </del> <ins> ), when deployment can be assumed for a given use case, or when implementation is signaled by some other property of the target resource.  This encourages a focus on mutually agreed deployment of common standards. </ins> 13.1.1.