Re: Proposed Text for RFC2445 Issue #1

[John Stracke <francis@xxxxxxxx>]

Eric Busboom wrote:

> I think we should add the FILE-NAME parameter to ATTACH.
>
> Without this parameter, an attendee will have a different name for the
> attached file than the organizer on the attendee's local store.

First, note that this is not a completely solvable problem.  If the attendee and the
organizer use different filesystems, the organizer may use a filename which the
attendee's system does not allow.

That being said, let's analyze the problem.  ATTACH: references fall into three
categories:

   * A "fetch a file" URL, which includes a filename.  (If it's an http: URL, the
     server can also use the Content-Disposition: header.)
   * A cid: URL, which references another body part in the MIME message, in which
     case, again, the sender can use Content-Disposition:.
   * Inline binary content.  This is the only case in which the FILE-NAME param
     might be needed.

If we introduce FILE-NAME, then the first two cases become problematic: what if the
FILE-NAME and the filename derived from the URL don't match? Different
implementations will make different choices, and you'll be right back where you
started.

Since the first two cases are probably preferable (they use existing general-purpose
infrastructure instead of something invented just for iCalendar), I'd choose not
hurting them over helping the inline binary form.

> company, no events older than 6 months were accessible. ) That means the
> document will be on my hard drive, seperated from the CUA, so it is going
> to need a sensible name.

Most documents have titles.  Most non-technical users probably like titles better
than filenames.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |I'm a .sig virus...and, boy, am I tired!     |
|francis@xxxxxxxx|                                             |
\==============================================================/