consequences of hashes controlling cache refresh

Graham wrote, quoting me

> >... It also occurs to me that
> >using a hash as an abbreviation to mess up the design goal you
> >mentioned at one point, of supporting indirection to a central
> >corporate profile which might change with time.
> 
> If true, I believe this would be a serious drawback.  I would like to
> understand why you think this happens.

Perhaps I'm confused. After all, I certainly feel confused about some
of the hash-as-primary-identifier proposals.  However, it seems
inevitable to me that this would happen, given that you also wrote

> I have always felt that the idea of cache-timeouts is a slightly
> unsatisfactory solution.  It works, most of the time, but an administrator
> is left with a choice between setting a long timeout and sacrificing
> responsiveness to change, or setting a short timeout and (potentially)
> sacrificing bandwidth.  Hashes can overcome this by forcing a cache refresh
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> exactly when it is needed.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^

Imagine that I have a company policy,
  (& (paper-size=letter))
which hashes to 0x1234, and which is stored at
  <http://my-company/policy.conneg>
On my birthday, the US passes the Privacy Assurance Act to make it
completely illegal for me to use cryptography, and my corporate policy
changes to
  (& (paper-size=A4))
which hashes to 0x4422 (and is stored at the same URL). Since
I use CONNEG indirection to propagate changes in corporate policy,
I figure that I don't need to update the mobile devices, only
the contents of the resource stored at the URL.

As in my original message, I see two possible modes for using hashes
as abbreviations in content negotiation:
  (1) Every time one of my company's devices opens negotiation,
      it sends both the hash and the URL. In that case, after
      my birthday, my mobile devices keep sending in the hash 
      code 0x1234, and the URL. The servers could check the URL,
      but they don't, because they use the hash value to decide
      when a cache refresh is needed, and the hash value 
      hasn't change. So they continue to use paper-size=letter.
  (2) Every time one of my company's devices opens negotiation,
      it sends only the hash. Again, after the changeover, the
      devices still send the hash code 0x1234, and the servers
      fetch the old paper-size=letter properties from their
      caches and use that.
Given that you want to use hash values to force cache refresh
exactly when needed so that there don't need to be cache timeouts,
it seems to me that unless you modify the hash values stored in
every individual client device, you will end up with stale hash
values being used to retrieve stale cached values, not the true
indirection which is needed in order to centrally control policy.

  Bill Newman
  [email protected]