Hmmm. If 'value' is redefined for all of MIME, won't it break
existing MIME implementations and thus have a negative impact on the
installed base?
Depends. You redefined RFC 822's "phrase" without having a negative impact
on anything (except perhaps the aesthetic value of raw RFC 822 mail :-)).
Yes, but that impact was deliberately limited to display-only text.
(and I've fought hard to contain the damage!)
A fine thought. These can't be represented at all now. If the encoding
(like 1522) fits into the old grammar, then old MIME implementations will
see a syntactically valid but very ugly parameter value (again, like 1522).
Yeech. I had hoped 1342/1522 would be the last time we ever had to do that.
All I want the C-D RFC to say is that, when the problem is solved for MIME
in general, the same solution should be used for C-D, either explicitly
(via a revision) or implicitly. If you can think of better words for that,
I'll be happy to use them.
I guess I was wondering if the problem ever would be solved for MIME
in general, as opposed to just solving the problem for new MIME
extensions. What do other people think will happen?
Keith
------------------------------------------------------------------------------
Hmmm... how about using "'" as the delimiter for b64-encoded strings?
At least that way they wouldn't be so ugly. Nice thing about using
b64 is that it doesn't use tspecials except for '=', and those only
appear at the end. So if the "="s are omitted, all strings of b64
characters fit into the MIME grammar for "token".
value = token / quoted-string / b64-string
b64-string = "'" [ ":" charset ":" ] *b64-char "'"
b64-char = any of : A-Z a-z 0-9 / +
; trailing "="s are omitted
charset = token
Example:
Content-Disposition: attachment;
filename=':iso-8859-1:L3Vzci9pbmNsdWRlL2Eub3V0Lmg'
(I guess base64 is pretty ugly no matter how you delimit it!)