Definition of "variant" and "requested variant", was: New "200 OK" status codes, PATCH & PROPFIND

Roy T. Fielding wrote:
> ...
> No.  The variant is not an entity.  Think of variant as the target
> of a request once URI+Vary-fields is taken into account.  It is the
> resource-as-subdivided-by-negotiation, which was the original definition
> before it got mixed up in committee.  Now, if we add the notion of
> a method that acts by indirection (PROPFIND), then we merely add
> that notion to the definition in general.
> 
>    variant
>       The ultimate target resource of a request after indirections
>       caused by content negotiation (varying by request fields) and
>       method association (e.g., PROPFIND) have been taken into account.
>       Some variant resources may also be identified directly by their
>       own URI, which may be indicated by a Content-Location in the
>       response.
> ...

The problems that I see here are:

1) for PROPFIND and friends, not only request header fields and method 
names, but also the request *body* select the variant -- I don't have a 
problem with that, but it should be spelled out.

2) a bigger problem IMHO is that allowing this additional level of 
indirection creates different classes of entity tags. Example: Entity 
tags returned in GET/HEAD/PUT/POST/DELETE can only be used for 
GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH. I'm a bit 
concerned about that.

Best regards, Julian