ietf-822
[Top] [All Lists]

Re: Last Call: Multipurpose Mail Extensions to Proposed Standard

1992-03-31 11:37:13

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