Usenet News is the name given to a network that transports ASCII text News articles. (eMail is said to consist of text messages. Usenet is said to be made up of "News Articles").

Usenet is sometimes mistakingly called Internet News, or Newsgroups. Usenet is not a part of the Internet, although a large part of the traffic between Usenet servers now go over the Internet.

ASCII is a character-set table, consisting of 128 characters: the table starts of with control codes, some punctuation characters, the numbers, more punctuation characters, and the upper- and lower case characters. (NOTE: 7 bits is enough to make 128 possible combinations - hence the fact that Usenet is a 7-bit system!)

There is a copy of the ASCII table at: www.asciitable.com

UUE stands for Unix to Unix Encoding. It's the standard encoding method in use on Usenet today.

It makes 8-bit binaries compatible for Usenet by dividing every 3 bytes of original data over 4 bytes out leaving 2 bits in each byte 0. This is where the extra 33% overhead comes from.

yEnc is a new encoding method for binaries on Usenet. It takes advantage of the fact that today (2001) Usenet is nearly 8-bit clean - all 8-bit characters are supported except for the characters CR and LF (these should only appear in the body of an article together, and only at the end of every line), and NUL. In other words, 252 characters ARE allowed, compared to 64 for UUE.

Usenet is now nearly 8-bit clean. A new encoding method like yEnc can take advantage of this and be MUCH more efficient than the other methods. yEnc is a better alternative to UUE.

Having a new encoding method meant you could also introduce checks to make sure that the file is uncorupted.

Typically yEnc has only about 3% overhead. This is a saving of roughly 35% compared to other encoding schemes.

It must be noted that because UUE adds a lot of redundant information when encoding (two bits are 0 for every byte) it can be compressed much better than yEnc files. This means that if you up- or download using a modem (or anything else that uses compression) the net gain of using yEnc instead of UUE is 'only' 11% or so. Cable users and similar will notice the full 35% difference.

Your NSP will also see a 35% reduction in needed storage space, if they save yEnc files as-is. The storage space savings, because of yEnc, will only grow as Usenet grows although these savings may be undone as people may be able to post MORE.

It's new, so it's not supported natively by Newsreaders. It's at the stage where UUE was 10 - 15 years ago. That said, support for yEnc is growing VERY rapidly.

Note: Agent 1.91 with yEnc support has now been released, so one of THE standard Usenet programs (the other being MS LookOut Express) is now compatible.

Some gateways do not handle yEnc well. Everyday users of Usenet should have no problems with yEnc though.

Like... what do you mean? It works 'right' for those things it replaces - UUE.

The idea was indeed to do yEnc in MIME. Unfortunately, the person who developed yEnc has NO knowledge of MIME. When he asked people who DO know, they told him it couldn't be done. yEnc may be implemented in MIME once MIME has been updated.

There's also the fact that not many Newsreaders are capable of MIME. Those that are, support MIME to different degrees. This means that if yEnc had been done in MIME most people would not have been able to use it. All Usenet software would first need to have been made MIME compatible and then include yEnc support - a LOT of work. In comparison, just implementing yEnc the way it is now is very easy.

Remember that UUE (the standard encoding on Usenet at the moment) is not done in MIME either, and that the amount of MIME on Usenet is not even 1%.

This is most likely due to the fact that some early yEnc programs were poor implementations. The most (in)famous is probably PowerPost 2000 which added a wrong CRC32 to each part. When these parts were then decoded the decoder, quite rightly, told the User that the calculated CRC32 does not match the one given. If you can, tell the encoder to ignore/skip the CRC check.

No, it doesn't HAVE to be there. This is purely there to let other Users know your post contains a file that's been yEnc encoded. Newsreaders should check the body of the article to see if there's a line starting with '=ybegin' to identify a yEnc post.

A yEnc v2 is being discussed. The following extensions MAY be implemented:

yEnc encoding

• variable offset (the v1 standard offset is 42)
  This small (but potentially very effective) optimisation is very easy to implement. A side-effect of this is that the escape offset will also have to be variable.

yEnc article format

• MD5 file identification
  Be able to positively identify a file BEFORE downloading.
• GZIP/ZLIB compression
  A standard compression built into all Newsreaders.
• PAR files
  recover corrupt articles (as opposed to parts or complete files).

yEnc suggestions / recomendations

• Automation
  Being able to identify files by a MD5 will make a lot of automation possible - your Newsreader can ask for missing parts, ask for reposts of corrupt parts, and if it sees a request for a repost fill in the gap for someone else.

That's the whole idea. Usenet is designed to transmit text. So if you want to post anything thats NOT text it has to be encoded so that it LOOKS like text. EVERYTHING posted to Usenet is 'text'. It's your Newsreader which recognises that a post is encoded and turns it back again to the file you wanted.

If your Newsreader does NOT recognise a post and only shows it as text it means it does not support the encoding used.

yEnc is not an alternative to mp3 (or any other file type). It's a way to encode files so it's possible to post them to Usenet. You can keep on using mp3's and all other files you like.