At 8:04 PM 1/25/95, Keith Moore wrote:
My question is still: should we use encoded-words in values?
The counter-proposal you first made was:
value = ( token / quoted-string / base64-chunk-list )
base64-chunk-list = [ charset ] "[" *base64-chunk "]"
base64-chunk = 1*17 ( 4*4 ( b64char ) )
b64char = Any of the ASCII characters:
"A"-"Z", "a"-"z", "0"-"9", "+", "=", "/"
The 's look to me like a potential problem; I would prefer to substitute
a non-special character for them, such as ':
base64-chunk-list = [ charset ] "'" *base64-chunk "'"
Now we have something that fits into the old grammar (assuming we drop the
= filler from the base64 encoding) and so won't cause parsers to hiccup.
For sake of brevity, let me call base64-chunk-list "64list".
Do you still think this is a good idea?
So, assuming we want to encode the word "Olé", we get:
or "=?iso-8859-1?B?X1X2X3X4?=" (indulge me on the base64 encoding, Ok?)
Basically, 64list is the base64 flavor of 1522, minus the provision for
multiple words and with different delimiters.
- 64list is shorter
- 64list cannot have special characters left in by mistaken encoders
- 64list does not have funny whitespace rules
- 64list allows pure binary (ie, missing charset)
- 64list is never even partially human-readable
- 64list has no provision for very long parameters
- 64list cannot mix charsets
- 64list looks nicer (this is a disadvantage in my view, since it increases
the likelihood of collisions with real values)
- 64list requires new encoders/decoders to be written
As I said before, I like 64list fine. (In fact, I'd be happy to see it
replace 1522 altogether (yes, and just lose the (dubious) partial
legibility and (confusing) whitespace rules).) Others, however, seem to
think it's not really very different from 1522, and so why bother?
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."