Larry Osterman wrote: > Out of curiosity, what are those issues? Is yEnc already encumbered > with the same legacy interoperability issues that prevented uuencode > from being standardized?
Essentially, yes. See these implementation notes <http://www.yenc.org/yEnc-Notes3.txt>. My question is that if you first gzip the output (which I appreciate will only slightly reduce the size of some image and sound files), won't you be able to avoid long runs of NULs (due to the run length encoding). If so, why not skip the rotation step entirely, simply escape the NULs, CRs, and LFs, and add a CRLF every 900 or so characters. Of course, this should be defined as a C-T-E. Since Section 5.2.2 of RFC 2046 restricts message/partial to be 7bit only, it would also seem worthwhile to specify an application/news-partial with nearly identical semantics, except for allowing use of 8bit content. You would need to specify whether non-8BitMIME gateways were allowed to re-encode the content into base64 (yes, thereby violating the MIME no double-encoding rule), or whether they should just drop the message on the floor. The main lesson from yEnc, I believe, is that implementers and users *will* adopt new technologies, if they add value. An 8bit-safe gzip C-T-E would add real value. - dan -- Dan Kohn <mailto:[EMAIL PROTECTED]> <http://www.dankohn.com/> <tel:+1-650-327-2600>
