Re: New I-D Transfer Encoding for MIME

I don't find a lot to like in either proposal.

Compression:

- Most really big data types have integral compression (sound, video, 
images, etc) and applying another compression algorithm to them is 
pointless or harmful.
- Even when you can get compression (such as with text), I'm unconvinced it 
buys you much.  There's so much low-layer compression going on.  I would 
like to see numbers indicating a solid benefit from application layer 
compression in email, a benefit worth the deployment penalty.
FILE/FS:

- First of all, I fail to follow the argument about why this needs to be a 
top-level type.  Huh?
- Why isn't this multipart/fs?  Lots of good things would come from using 
multipart.  I get the feeling the author has some reason he doesn't want to 
use the multipart construct, but the draft doesn't say what it is.
- The draft makes an assertion that using file/fs will promote 
interoperability between platforms.  However, all the data typing, 
canonicalization rules, etc, that we now do with MIME are not used.  In 
fact, all the interopability onus seems to be put on the receiving system. 
Eg, I send you a Macintosh filesystem, one of the files has Macintosh type 
'ttro'.  From this, a receiving UNIX (eg) mailer is evidently supposed to 
intuit that this is a text file and apply text canonicalization on 
unpacking.  Seems hard.
- I am skeptical that the type can adequately represent current and future 
filesystems.  In current form, I don't see how it can represent critical 
items from the Macintosh filesystem (for example, the Macintosh filetype I 
mention above. I'd be interested to see what Ned has to say regarding VMS 
here.)  Perhaps specific problems of current filesystems could be coped 
with by adding to this draft, but it seems to me that for future growth 
we'd wind up needing to reinvent a lot of the registry and standards 
process we already have, for use inside this thing.
- Perhaps this is just a first-draft problem, but there are various minor 
strangenesses.  Section 4.6 seems to forbid using message/partial to 
transport file/fs objects; why?  4.7 mandates that applications use CD: 
attachment; why?  4.3 mandates using ".fs" on the end of filenames; why?
It seems to me that the proposal throws away lots of good work that's been 
done with MIME.  I agree that it would be nice to have a way to transport 
filesystems, but I think we would be better off working on something like 
multipart/fs along with some new Content-Disposition parameters or 
something.