In <01KG3T1CQDU400004D(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
Well, yEnc as presently formulated has a failure mode where some messages
will grow to 2X their original size. I also don't like the fact that
it shifts the range of almost every character. It is possible to fix both
of these problems and have an encoding with an upper bound guarantee that
leaves the original data mostly untouched.
Just my personal take -- neither of these are necessarily showstoppers.
I think every encoding scheme has a pathological case which produces a "2X
their original size" situation.
On the contrary, the vast majority don't have any such case. base64, uuencode,
and base85, for example, consistently increase size by 33% or 20% no matter
what the input.
The yEnc class of encodings readilty admits a block-by-block approach that
_guarantees_ at most 2-3% overhead.
I think such an accurrence is wildly improbable in the yEnc case.
Unlikely, perhaps. But wildly improbably is a stretch. And why take the
chance?
AIUI, the reason for the range shifting is that the NUL character tends to
occur with more than its random probability in typical binaries (even to
the extent of huge sequences of NUL bytes). Therefore, it is desirable
that NUL itself can be transported without stuffing (or course, some other
random character then gets saddled with that honour).
Sure, but there are ways to accomplish this that don't require blanket
range shifting.
Ned