Stef: had the impression at one time that we were bulding a system of
Stef: indentifiers that let us cascade a set of processes to be applied to
Stef: various body part objects.
Yes! This is a very good way of describing what I suggested yesterday.
I see no good reason to limit ourselves to two transformations in
order to reach a mailable object. Or 3, or 4, or ...
The syntax to have an arbitrarily sized list of transformations is easy
to put in. It just borrows the same comma-seperated paradigm used in
many other header lines. Occasionally To: lines get to be Really
Really long, but normally they stay at <= ~5 and everything is fine
either way. It should, IMHO, be the same with Content-Encoding:.
To bring up `uuencode' again. Someone (Nathaniel?) yesterday mentioned
that his impression was that it wasn't strongly "standardized", and therefore
not someting to include.
My experience is that while there are a few slight variants on the
theme, that all (with possibly one caveat) were compatible with one
another. Most of the extensions were to place extra information after
the claimed end-of-line. That is, each line starts with a character saying
how many data bytes are on this line. The uudecode program reads that
many characters off and proceeds to the next line. Which means that any
extra data is not seen by a uudecode which doesn't expect that extra
data to be there.
The stock uuencode which has been distributed with 4.{2,3}BSD does
have a problem with using trailing blanks. One of the "extensions"
was to simply add a non-blank character to the end of the line.
Another (this is the `caveat' mentioned above) changed the encoding
so that it did not use blanks, this one is likely incompatible. Another
added a checksum to each line. They are all intercompatible, I have
used them all and stared at all the source code, etc.
I strongly feel that uuencode should be mentioned as one of the
possible encodings. Not because it's any more efficient or "better"
than the others, but because it's widely implemented, widely available,
and widely known. For a recipient who does not have an RFC-1154++
complient UA which cannot decode these funky messages we're talking
about, they likely will not know what to do with this weirdo looking
stuff in the middle of the message. But by using something familiar to
lots of people, there is a greater chance that the message will be
decodable.
David