Why yEnc is Good for Usenet

Sean Russell

60252 Rimfire Rd.
Bend, OR, 97702


This is a rebuttle to the essay "Why yEnc is Bad for Usenet"

I'm a software developer. Consequently, I both use software and have to use specs that others have written. By and large, I feel that CS (computer science, information science, whatever you want to call the field) suffers from too much ivory-towerism. Most specs are overengineered, needlessly bloated, and oversolve the problem they're trying to address. This makes the spec difficult to implement, and resulting APIs (for libraries) difficult to use. This would be acceptable except for the fact that, in most cases, most of that bloat is a result of the 80/20 rule: 80% of the bloat c omes from 20% of the functionality, and usually the 20% nobody uses. SGML, SOAP, DOM... the list of difficult, yet "properly", designed specs is large. While this may not directly apply to the hypothetical "correct solution" you describe, it does relate to another problem with CS: many of these specs are poor because they're defined by Committies. I use a capital "C" because I refer to that special breed of groups of people who seem to be more interested in sitting around discussing, politicking, and who are so assured of their own importance that they take several years to do what any reasonable, sane person can do alone -- with community input -- in a couple of months.

I like yEnc: it works, and it is there now. It solves a problem, without waiting for another 10 years for the "specialists" to come up with their solution. I like it specifically because it provides a REAL solution, not a vaporware promise of a shiny future. It isn't perfect, but then again... neither is MIME, and MIME was designed by "specialists".

One last point: if the correct solution involves "fixing" MIME, I fully expect we'll be using yEnc for decades. 40% space savings is a powerful argument for even a bad design. Defacto standards may not be the best, but in a vaccuum of alternatives, they're better than nothing.