I think that we have closed on the question os what characrters to use
in our base64, adn thanfully they agree with PEM-DEV! I do not wish
to reopen that question or prolong its life as an open question!
[From: rja7m(_at_)acacia(_dot_)cs(_dot_)virginia(_dot_)edu
[Date: Fri, 10 May 91 08:10:37 EDT
[Message-Id:
<9105101210(_dot_)AA10501(_at_)acacia(_dot_)cs(_dot_)Virginia(_dot_)EDU>
[In-Reply-To: Einar Stefferud <Stef(_at_)ics(_dot_)uci(_dot_)edu>
[ "Re: EBCDIC & uuencode/uudecode" (May 9, 11:26pm)
[Subject: Re: EBCDIC & uuencode/uudecode
But, Randall has mentioned several things that were beyond the scope
of any of my remarks, and I want to clarify this. My opening comment
was entirely focues on the base64 characters to be used in the
encoding, adn has nothing to do with any other encoding, especially
uuencode!
[On May 9, 11:26pm, Einar Stefferud wrote:
[Subject: Re: EBCDIC & uuencode/uudecode
[% To me, our objective is to make our mail systems reach out as far as
[% possible without making trouble for anyone. This means that we must
[% not take a provincial postion with regard to "INTERNET USASCII IS ALL
[% WE CARE ABOUT, AND TO HELL WITH THE REST OF THE WORLD!"
[I think that there is clear consensus that US ASCII is not sufficient
[for text mail messages. It is however supported by the current
[installed base of RFC 822 compliant sites. This makes it a clear
[common starting point. It is equally important to not take the
[provincial position that "Western languages are all we care about and
[to **** with the rest of the world."
I did not mean to say anything about any other encoding, including
character sets that might or might not be useful for "text".
[% It seems clear to me, and I suggest that we conclude that we have
[% consensus on this, that we need to use a base64 encoding that will
[% pass without any translation ambiguity trouble through as many limited
[% and troublesome character encodings as possible.
[I agree with the concept that if one is going to devise such encoding
[algorithms that it should try to be as portable as is practical. I
[would disagree with the idea that existing uuencode/uudecode should
[be changed in such a manner.
I agree that this particular discussion has nothing whatever to do
with uuencode. I wish I had removed the wordS "uuencode/uudecode"
from my "Subject: Re: EBCDIC & uuencode/uudecode".
[% The list of "charcter set environments" what we want to pass unscathed
[% includes (USACII, other non-USASCII 7bit codes, EBCDIC, 8859/n, and
[% Printable String). Are there any others? Lets agree on this list!
Again, I was only refering to the character set environments that we
need to pass our base64 through without damage, not what characters
sets I want to support in "RFC-XXXX.
[I think that there are two or three questions here that we need to keep
[clearly separated:
[ 1) which character set encodings should be supported/required
[ for text mail traffic ?
[ 2) should a replacement for uuencode/uudecode be devised and
[ included in the replacement for RFC 822 ?
[ 3) if the answer to 2 is yes, which glyphs should be used in
[ the new scheme ?
From my perspective, these are new questions, unrelated to the base64
question, and thus the rest of Ransall's message shoudl be regarded as
addressing a new set of issues.
[My views follow:
Remaining text removed since I have no comment on it.
[Randall Atkinson
[randall(_at_)Virginia(_dot_)EDU
I do not know anything about uuencode except that when I try to use it
to decode stuff that I receive, it does not work very often, if ever.
Best...\Stef