To date, MIME is specified such that it can be generated (and sent) in a
stream, without requiring the entire contents be kept in temporary memory while
the length is checked and recorded in the header. I would consider that any
new CTE keep true to this valuable design principle. This is an important
characteristic for low-memory devices that record and send large
stream-oriented message files (voicemail / mobile videomail). These
applications would be great candidates to use the compression/8-bit CTE's being
discussed.
Greg V.
-----Original Message-----
From: Lyndon Nerenberg [mailto:lyndon(_at_)orthanc(_dot_)ab(_dot_)ca]
Sent: Friday, February 28, 2003 3:39 PM
To: Charles Lindsey
Cc: ietf-822(_at_)imc(_dot_)org
Subject: Re: gzip-8bit
One of the features of YEnc IIRC (and it had many "features") was an
indication near the beginning of the total length in bytes. In the case of
a compressed stream, of course, that should be the uncompressed length so
that implementations can detect early on that the length exceeds the "house
limit" and abandon the decoding.
Does yenc provide integrity protection of the length value? Or can
I lie and say the 20GB uncompress data is really just 1KB?
--lyndon