Re: Proposed Text for RFC2445 Issue #1

[Bruce_Kahn@xxxxxxxx]

John proposed:
>   * Deprecate the inline-binary syntax for ATTACH, in favor of using data: URIs (RFC-2397).
>   * Write a document extending data: URIs to permit arbitrary Content-* headers (a Good
>     Thing for many purposes, not just calendaring; for example, tagging inline content with
>     Content-Language).
>   * Now, if you want to send an inline attachment with a filename, use a data: URI with a
>     Content-Disposition.

I have a concern about backwards compatability here and usefulness of the effort.  The bullets effectively replace the current inline form with another to "fix" an issue that noone seems to have really run into yet in their engines that Ive seen.  While Im no fan of the inline binary (a last minute addition by Ye Ole Editors w/o any WG air time), I do not want to make changes that breaks work thats already been done and in use.

Wouldn't it be much much simpler to NOT inline ATTACHments that you want to convey such meta information for and instead put them into their own proper MIME body part w/the desired headers??  For the quite rare case of wanting to inline 'em you lose that info??

I did an admittedly quick survey of ~5 active C&S users here and I could find _0_ attachments under ~200K (.DOC files).    The _vast_ majority were larger  typically .ZIPs of presentations or overheads averaging well over ~325K.

Unless there is some real interest in keeping inline ATTACHments then why not just remove the ability outright?  Its simpler and faster than doing all the bullets.  That way I can keep the existing code that works for vCards (where my SOUND, LOGO and PHOTO all are inline) w/o writing new code for a case that IMNHO is less than .5% of the ATTACHment cases...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...