Subject: Re: Proposed Text for RFC2445 Issue #1

From: [email-masked]
Date: Wed, 4 Oct 2000 16:11:22 -0400

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: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Thu, 05 Oct 2000 08:43:40 -0400

[email-masked] wrote:

> 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??

Yeah, that does make sense.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"But she calls her ship _Mercy of the Goddess_!"|
[email-masked]|"Kali." "Oh."                                   |
\=================================================================/

---

From: Eric Busboom <[email-masked]>
Date: Fri, 6 Oct 2000 10:26:15 -0700 (PDT)

> Yeah, that does make sense.

If inline attachments for which a file name is important are going to be
rare then I wouldn't mind ignoring the issue. 

Then, unless there are other objections, I will REJECT RFC2445 issue #1. 

Perhaps we should also add a bit to the Implementors Guide, suggesting
that implementors stick to non-inlined attachments if the filename is
important.

Now, what do you think about issue #3?
	http://www.imc.org/ietf-calendar/mail-archive/msg04618.html

eric.