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:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>