[kde-linux] Re: Request for multiple monitor xorg.conf files? - "jed.monitors.conf" (001/001)

[Duncan]

Pascal Bernhard posted on Tue, 28 Jun 2011 07:32:58 +0200 as excerpted:

> Hey Duncan,
> does yenc have any advntages over traditional, 'old-school' stuff like
> UTF8?

They're orthogonal concepts, so your question doesn't have a direct 
answer, but the (if I may) implied question, why the bother, is none-the-
less rather interesting in itself.

The basic problem is that the original email standards were designed with 
7-bit ASCII text data (and a restricted set of that) in mind, and aren't 
directly compatible with normal 8-bit binary files, which must thus be 
"encoded" using some scheme or another into some form that can be 
reliably transmitted thru the mail system and then decoded on the other 
end, without loss or damage to the binary data, which could after all be 
an executable or something else sensitive to bit-flipping or similar 
damage.

One of the first such encodings ('80s, perhaps earlier) was called unix-
to-unix encoding, aka uuencode or simply uue.  There's of course a 
wikipedia entry for it if you want the details.  A somewhat better and 
more standardized solution introduced with MIME (multipurpose internet 
mail extensions, developed early-to-mid-90s... wikipedia...) 
standardization was base64.

The problem with both uuencoding and mime/base64 encoding, however, was 
that they used a subset of 64 (reliably transferable) printable ASCII 
characters to encode 6 bits per printable character, but these printable 
characters themselves were normally encoded in 8-bit ASCII both "on the 
wire" and as stored in the files containing the messages at each end.  
Thus, it took 8 bits to encode 6 bits worth of data, and the resulting 
space and bandwidth required was normally 4/3 (or more, due to other 
overhead, 33-40% overhead) that of the actual binary file size.

In 2001 J Helbing introduced yEnc, sometimes called yyencoding in 
reference to the original uuencoding.  yEnc was designed and very quickly 
became *EXTREMELY* popular on USENET, because it cut the overhead to a 
much more manageable 5% or so by taking advantage of the fact that nearly 
all of USENET was operating on 8-bit safe connections by that time.  The 
cut to ~5% overhead *MATTERED* to people generally on sub-megabit 
connections or even still on <56k dialup at the time, so yEnc very 
quickly became the de facto standard on binary newsgroups.  In fact, it 
became SO popular SO fast, that the format really had no time to evolve 
into a proper standard.  As a result, some of the weaknesses of the 
original uue that had already been corrected in mime/base64 were 
reintroduced.

While there has been talk of formalizing the standard, by the turn of the 
century USENET was already in some decline, and the various political 
realities that had such an effect on P2P further discouraged formal 
standardization, so it never really happened, and yEnc support remains 
even today somewhat hit or miss, especially for mail clients, tho a 
binary news client that doesn't include yEnc support really can't be 
considered a serious binary news client at all, these days.

Meanwhile, alternate charsets have had their own problems and history 
with the originally ASCII internet message standards, but the solution 
for them has evolved somewhat differently, including the UTF-* family of 
standards (UTF-7, UTF-8, UTF-16...).  However, to some degree at least, 
the UTF-8 and UTF-16 variants often end up mime/base64 encoded, because 
official Internet message standards are still MIME based, despite the 
33-40% overhead this normally causes.

yenc itself has some UTF-8 issues as well, but UTF-8 seems to be driving 
the process of standardizing the bit-space forward now, taking the place 
ASCII originally had, and should USENET and email not fall toward the 
irrelevance of say the old gopher protocol, eventually an updated MIME 
standard will likely emerge that will address the bit-space problems both 
binary file attaching and UTF-8 text encoding have.

There however does remain one loose end within the current context.  
Standard ASCII text files don't normally /have/ to be attached as binary 
encoded tho they often are simply because the client seldom makes the 
distinction between binary and text file.  Instead, they can be "identity 
encoded", which more or less means simply cut-and-pasted as the text they 
are.  In a strictly MIME context, they can be attached as another text-
type MIME message-part, or they can simply be either directly pasted into 
the message itself or appended to it, forming part of the main message 
body text.

That of course is what I've not decided, whether I'll simply (re)send 
those files appended as text to the message, or uue attach them.  (FWIW, 
due to the limitations of pan and the tools I'll be using to manually 
attach the files since the new toy only does yenc binary attachments, 
MIME/base64 attachment isn't an option at this end.  I can now auto-
attach as yenc, or I can use a script I designed myself to attach as UUE 
or identity-encoded-text in what without the script would otherwise be an 
entirely manual process, but I don't have the MIME/base64 option.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman