Re: consequences of hashes controlling cache refresh

At 02:15 PM 2/6/99 +0000, Graham Klyne wrote:
>
>Turning to [Bill Newman's] 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.
>

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