[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: base64 behavior is not MIME compliant
From: |
Richard M. Stallman |
Subject: |
Re: base64 behavior is not MIME compliant |
Date: |
Sun, 03 Jul 2005 16:43:04 -0400 |
RFC 3548 has this to say about characters not part of the encoding
alphabet:
Implementations MUST reject the encoding if it contains characters
outside the base alphabet when interpreting base encoded data, unless
the specification referring to this document explicitly states
otherwise. Such specifications may, as MIME does, instead state that
characters outside the base encoding alphabet should simply be ignored
when interpreting data ("be liberal in what you accept").
Words such as "must" claim an authority we do not recognize in the GNU
Project. We do not _obey_ standards--rather, we see what they have to
say, consider their recommendations, then do what seems best.
I believe the best fix is for base64-decode-region to take an optional
argument which specifies how liberal it should be about it's input,
defaulting to the current behavior, and for Gnus to use this argument.
To decide whether to do this, we need to know the answers to three questions:
Is there some situation in which the current behavior of
base64-decode-region causes an actual problem or confusion for users?
Is there some situation in which the current behavior provides an
advantage?
Also, how does the current development Emacs handle these things?
Your report is based on 21.4; the current sources may be different.
Of course, Gnus
can fix this independently by using an external base64 implementation
which is MIME-compliant.
Theoretically it could, but that's a very undesirable thing to do, so
we won't do that. If this calls for fixing, we should fix it in
base64-decode-region; if not, we shouldn't fix what isn't broken,
not in Gnus or anywhere else.
- Re: base64 behavior is not MIME compliant,
Richard M. Stallman <=
Re: base64 behavior is not MIME compliant, Arne Jørgensen, 2005/07/05