Subject: Re: consequences of hashes controlling cache refresh

From: Graham Klyne <[email-masked]>
Date: Sat, 06 Feb 1999 14:15:05 +0000

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-masked])

---

From: Al Gilman <[email-masked]>
Date: Sat, 06 Feb 1999 10:27:01 -0500

At 02:15 PM 2/6/99 +0000, Graham Klyne wrote:
>
>Turning to [Bill Newman's] earlier message:

Thank you for this good exposition of the functions or performance axes
that are of concern in this scenario.

OTOH I beg to differ with you "cannot" clauses and relate them to the
notion of an URN.  And I would note that locally-generated hashes only
support identification and verification with a small but finite chance of
error.  It depends on the criticality of identification and verification
errors whether locally-generated hashes are accepted as meeting these
requirements.

Architectural specs should cite URIs and not URLs is setting up frameworks.
 One can see why in this case.  A URN is designed to support all four of
the functions needed here.

We can make an URL meet the identification and verification requirements by
local policy at the site assigning the URLs to feature sets.  Compare with
'mid' URLs.

We can make a hash meet the location requirements by supporting a
nameservice that dereferences from hashes.  We can also make the hash truly
support identification and verifications (without even the small likelihood
of error) by publishing through a central archiving hash server.

So either an URL or a hash may attain the status of an URN by wrapping it
in suitable services that are not implied purely by its status as URL or hash.

If you want an URN, get the URN-mavens to design you one.  

Al

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 6 Feb 1999 20:40:25 PST

There are other ways to get 'location' from a hash than
by also providing a URI. For example, in HTTP, a new response
header could request the sender f an accept-features to
supply an expansion of a hash.

In some circumstances, the URI for expanding multiple hashes
in the various feature expressions could be constructed
using a hash-expansion base, where the URL for a given hash
could be constructed by appending the hash to the base.

In both of these situations, there might not be a 
one-to-one relationship between "hash" and supplied URL; in
the first case, there is no URL corresponding to the
source of the data for the hash, and in the second case,
only one URL element is supplied, and the URLs constructed.

Larry
-- 
http://www.parc.xerox.com/masinter