When working on issue 2551068 to download file/msg via the binary_content attribute,
I realized the ETag for the whole item is being emitted. Not just an etag  on the
returned data.

Is this correct?

Conditional gets for an attribute (binary_content) could fail if some other field
on the item is updated. For large contents like binary_content this could lead to
unneeded downloads.

Should the ETag for an attribute endpoint be calculated just on the content being
returned? This could be done by changing the current etag calculation routines to
include optional attribute argument so the etag is calculated only on the attribute.

Setting an attribute (patch/put) requires the entire items ETag. I think this
is correct. The attribute's value could be the result of calculations on other
parts of the item. So verifying the state of the whole item when changing an
attribute makes some sense.

However, the attribute change could be based only on the prior value of the attribute
so an etag on the attribute only would be sufficient.

For safety, I think requiring an item's etag (and not attribute etag) is the right
thing to do when updating.

As a result, if we don't send the item ETag on an attribute get, the user can't
request an attribute and change it without also requesting the entire
item so they have an item level etag that can be used to modify the item.

In the classic tracker binary_content of a file is immutable (in theory). So maybe
conditional get isn't an actual issue?? But if you allow editing content....