Excerpts from mail: 30-Oct-91 Re: several comments on RFC.. Timo
Lehtinen(_at_)sti(_dot_)fi (955)
The whole idea of doing multipart in RFC-934 the way (ASCII,
with boundaries etc.) is to be faithful to the text message
philosophy. Apart from that a binary encapsulation format ala
NeXT (i.e. tar->compress->uuencode) would be much more functional
- and in fact is more functional than the current RFC-XXXX draft.
Well, certainly RFC-XXXX has nothing like tar; beyond that, I don't see
any functionality differences (compress is a tradeoff between efficiency
and portability; we've opted for portability).
Adding tar-like functionality is precisely what's under discussion here.
What people want in the XXXX context, of course, is something that
isn't nearly as UNIX-only as tar. And there you open the whole can of
worms of file name syntax, directory structure, and so on. I think it's
one best left for another RFC.
Is the XXXX functionality "loaded" in the sense of being fairly large
and complex? Perhaps, but for a good reason. There are LOTS of simpler
solutions. Andrew is one. Slate is another. Montage is another.
NeXT's use of tar/compress/uuencode is another, though I consider it far
too unportable to take seriously. The point of XXXX is to try to come
up with one interoperable format that can replace all of these. It
would be EXTREMELY surprising if it weren't more complex than most of
them. I think considering what it is trying to do and how many
different camps it is trying to satisfy, it is remarkably simple, but I
can understand your frustration and why you might not share that opinion.