[hashcash] Re: new format tweak coming...

(btw I set the list to non-subscribers can post just now as I'm going
to be travelling over the next few days, and posting via the nntp
server was resulting in me getting non-list post approve messages that
I have to fwd to get the msgs through, because it was not from list
subscriber.)

On Sun, Mar 14, 2004 at 07:38:06PM -0500, Hubert Chan wrote:
> Adam> so no quotes needed (either " or '), reserved are :;=, and so we
> Adam> use restricted url-encoding where only those are urlencoded.
> 
> If I understand correctly, you would only need url encoding within the
> extension field, and only for non-printable characters, right?  In that
> case, I think that you could just leave it up to whoever creates an
> extension to define what type of encoding he/she wants, but encourage
> the use of url encoding.

> I'm not against using url encoding.  I just think it's best to dictate
> as little as possible (or is reasonable).  I would imagine that someone
> might create an extension that is pure binary data, and would want to
> use base64 encoding instead of url encoding, since it's much more
> compact.

That's certainly a possibility.  The spec just says you must not use
:;=, in the value fields, and it's up to your circumstance to figure
out what makes sense for you.

The other side of this would be that if we defined a minimal encoding,
the only additional restriction is not to use \ (or rather to be aware
of the need to quote it).

I was actually thinking of having the hashcash utility do the decoding
and executing the handlers per variable so they get clean arguments,
such as:

hashcash -c 0:040315:foo:foo=bar,taz;zzz=1;xyz:fc4f8aa41f0d5aec

would result in the invocation of:

hashcash-foo bar taz
hashcash-zzz 1
hashcash-xyz

(and presumably you'd pass along the version, date and resource name
also (as the 1st 3 args, and perhaps the whole stamp for good measure
also as the 4th arg, then as shown above).

Then first we check the hashcash is valid as usual, then call all the
extension hooks (if they exist in the search path), check the exit
status if any fail the hashcash fails, otherwise it succeeds.

That way the extension handler wouldn't need to worry about decoding.

Of course when you create the token with hashcash -m you also need a
way to pass in the extension fields to include, and perhaps we can
find a convenient argument passing convention so that hashcash command
can do the encoding if required.


But apart from the tool encode / decode and extension hook mechanism,
you still want it to be very easy to parse a raw token in a number of
languages so some people's hashcash integration can still be literally
a sh script.

Adam

Other related posts: