Re: consequences of hashes controlling cache refresh

At 17:01 04/02/99 -0800, Bill Newman wrote:

>+ (S3) Providing an expression of corporate policy with respect to
>+ media capabilities.  For example, an organization might declare a common
>+ capability for incoming Internet faxes, so that detailed capabilities of
>+ each internal system do not have to be published.

I think it is entirely valid to test the hashing approach against the
proposed goals (even if this serves to indicate that the suggested goal is
unreasonable).

I think the fundamental of this goal is to provide an "expression" of
corporate policy, not a "propagation".

I don't expect that a typical mobile device would be responsible for
enforcing corporate policy:  I guess that would fall to corporate mail
servers.  But a mobile sender *might* cache the capability for
frequently-used destinations, and recognize the corresponding hash
advertised by the receipient.  When the corporate policy changes, the
sender would no longer have a cached capability and would then be forced to
retrieve updated capability information in order to determine whether or
not it matches the available send capabilities.

Exploring another example:  a mobile device acting as a web client would
presumably offer capabilities along with a request:  it then comes the
responsibility of the corporate web server to match those capabilities with
the current corporate policy.  In this case, the corporate capabilities are
not transferred.



Turning to your earlier message:
>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.

I think there are four distinct functions at work here:
    abbreviation    (representing a feature set in fewer bytes)
    verifification  (verifying a locally-held feature set is that intended)
    identification  (identifying a feature set)
    location        (indicating where/how to retrieve a feature set)

Hashes can serve the first three, but not the fourth.

URLs can server the first, third and fourth, but not the second.

The term "indirection" that you use here implies  "identification" and
"location".  In this respect, I concede that a URL can serve the purposes
of indirection where a hash cannot.

However, you indicated that you were also responding to my comment:
"Hashes can overcome this by forcing a cache refresh exactly when it is
needed".  I believe this requires "verification", which is not provided by
a URL.

My public proposals to date have involved a combination of URL and hash;
unfortunately this fares less well on the "abbreviation" front.  But I am
still thinking about approaches that can use hashes in conjunction with
URIs to provide the full range of functions.  I note that the "location"
function is the "last resort" in this scheme, and is only needed when a
cache refresh has been forced.

>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.

But, in your example, the hash value *has* changed from 0x1234 to 0x2244.
It is precisely this change that can force a refresh.

I now see the part of your scenario with which I disagree:
    >I figure that I don't need to update the mobile devices, only
    >the contents of the resource stored at the URL.
If the mobile devices are responsible to communicate information about
corporate policy then they MUST be updated.  On the other hand, if they are
simply saying that messages to/from them SHOULD conform to this policy then
they can communicate just the URL and let the counter-party deal with any
enforcement issues.

>  (2) Every time one of my company's devices opens negotiation,
>      it sends only the hash.

The hash can only mean "this particular version of coproate policy", not
"the current version of corporate policy".

>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.

Yes.

I think we are agreed that hash values do not, of themselves, provide an
indirectioin mechanism.

This has been something of a rambling response.  In summary, I see that
hash values can only be part of what is needed to address the particular
issues you raise.  But I hope I have been able to show that they can still
serve a useful purpose.

#g

------------
Graham Klyne
([email protected])