I like this. The savings in space and complexity that this proposal would deliver would go quite some way toward mitigating the effects of the infinite recursion that would be needed to encode the proposed URL for inserting obsolete characters like u, U and possibly the punctuation.

April 1st seems like a good date to focus on for this as I would rather finish one task before starting another. But building consensus on which subset of ASCII to use is the key bit, so that we can have THE MicroASCII format rather Yet Another MicroASCII format.

I can't really see any value in rushing into this until, say, April
at the earliest. We really need to evolve a consensus first.
Perhaps a draft RFC is appropriate? And a few robust implementations
would certainly help...

Michael
--
TeraText DBS Development, SAIC Pty Ltd.

On Thu, Jan 13, 2011 at 09:44:44AM -0000, Pete Cordell wrote:

This is an interesting proposal Rick. While I've no use for it myself,
I recognise that I don't represent every programmer, and if someone like
you finds it useful, there are likely to be many others that would also
find it useful.

In order to do this, I am proposing MicroASCII. This would restore
ASCII to its Latin essentials and reduce the insane repeats.
Syntactical sugar such as K, Y and Z are no-brainers of course: I doubt
that anyone will really miss them. But more recent fads such J, W and U
are better off treated as presentation forms and taken care of by
another layer: ASCII violates this basic separation of concerns.
Indeed, the whole lower-case is redundant.