| But I agree that in the end RFC-XXXX is already too loaded with features,
| and maybe multipart/archive can be worked out as a separate RFC. Any
| volunteers to help me write it (I'm totally new in this RFC business).
It's loaded, but not because it has a lot of functionality,
but rather because the architecture is not clean. The logical
equivalent to a part in a multipart message is a file.
There is no need to think of these too as being something
inherently different. The headers just allow for it to be a
typed file.
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.
ttl
P.S. I once wrote a nested archiver/dearchiver based on the 934
model and it worked nicely.