My vote: Go for it.
However, since it's been a couple of months since my last review of RFC-MIME
I'm doing another one, and have some corrections.
On page 14 (Postscript version), section 5.1 (Quoted-Printable). In Rule #2
it would be nice to have it list the characters which are excluded as well as
the ones which are included. In Rule #4, paragraph 2, it should read:
Note that many implementations may elect ...
not: Note that many implementation mays elect ...
Section 5.2 (Base64), page 17 (Postscript version) in the second paragraph
after the Base64 Alphabet (starts with "Special processing is performed...).
There is a sentence starting "Output character positions.." and goes on
to talk about `=' characters representing empty spots. This particular
sentence drew a big *HUH* when I read it, it became much clearer a couple
of sentences farther on fortunately. If this sentence is to serve as an
introduction to this concept it should be better worded. Example:
The character "=" is used in output data for places which require
output but there is no matching input data.
Now.. from the discussion here, it appears the ONLY time `=' is used is
for padding at the end. So is there need for this general a definition
of what it does? I remember we used to put line/record break markers
into Base64, is the generality of this a holdover from then?
I know this is an awfully late time to bring this up. Why was the
"cleartext" feature of PEM's Base64 removed from MIME's Base64. It
seems, now, this is a gratuitious incompatibility which may make us
non-interoperable with PEM's Base64. Having a cleartext capability
may, in fact, be useful. Are the PEM people going to adopt MIME's
modification of Base64, which would make the point moot? What should a
Base64 decoder do when it see's a `*'?
In section 7.3.3.1 (`ftp' and `tftp' (shudder) access types) it doesn't
discuss the login-name or password parameters. But in section 7.3.3.2
it mentions that `anon-ftp' does not require them. This also isn't
discussed in the appendices.
MINOR NIT--> Do y'all have to be so rough on the `conversions' idea?
If there were some effort at standardizating the names of conversions
would it be more palatable? BTW, both `uuencode' and `compress' (Unix
Lempel-Ziv version) are more `portable' at this moment than base64 is.
That is, they're available on many many many platforms while base64 is
not (yet) widely available.
Keld's name in the Acknowledgements came out `funny' (Postscript version).
I think the Base64 issue may be important enough to hold publication. It
depends on how long it would be held up; a week would be OK but longer
would be Right Out. Same is true for login-name & password parameters.
All the other comments are minor and can be held off until later.
David