[Top] [All Lists]

Re: EBCDIC & uuencode/uudecode

1991-05-10 21:55:39
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
[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

[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

[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

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.


<Prev in Thread] Current Thread [Next in Thread>