Re: Length of recent X-Hashcash cookies?

On Dec 15, 2004, at 2:30 PM, Simon Josefsson wrote:
> Hi.  I have been using X-Hashcash for a while, but the recent cookies
> are long (>80 characters), which look quite ugly.

Yeah... I found this as well.

In the Python implementation I wrote, I use more-or-less the "shortest 
tokens that obey the spec."  I use a short-ish default salt, and start 
my counter at one hex digit, only adding more if needed to find a 
match.  That makes for variable length tokens for the same resource, of 
course, but a fixed length isn't anywhere in the spec (and moreover, 
resources obviously differ in length, hence so do complete tokens).

It would be nice if the C version had a similar option to use "shortest 
possible tokens"... at least a non-default switch.

> PPS.  How about renaming X-Hashcash: to Hashcash:?  The 'X-' prefix
> also look ugly, and was only discussed in RFC 822, not in the current
> RFC 2822.

I disagree on this.  Even if 2822 doesn't mandate it, the use of X- 
prefix "special" headers is widespread, even ubiquitous.  I like 
hashcash, of course, but we should be nice to the header namespace.  
How would you like it if MS started renaming those awful 'X-TNEF' 
headers as 'TNEF' (whatever either means), or even if Spam Assassin 
used simply 'Spam' instead of 'X-Spam'.  The X- is a nice filter for 
optional or non-mandated RFC2822 headers.

Yours, David...

---
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.