Subject: Re: Proposed Text for RFC2445 Issue #1

From: John Stracke <[email-masked]>
Date: Mon, 02 Oct 2000 11:25:43 -0400

[email-masked] wrote:

> Well, it doesn't, since there isn't a problem with FMTYPE. The name of the
> issue is an error. ( I got the wrong Subject: line with the message. I
> should have declared #1 a duplicate of #8, and used the Subject from #8. )

Um.  <dig, dig> OK, well, we had one person post suggesting a filename, last
November, with no explanation why, and it doesn't look like anybody ever
commented; looks like we don't have consensus in favor of this one.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |In the long run, there is no middle ground   |
[email-masked]|between justice and genocide.                |
\==============================================================/

---

From: Eric Busboom <[email-masked]>
Date: Mon, 2 Oct 2000 12:17:57 -0700 (PDT)

> commented; looks like we don't have consensus in favor of this one.

Right, but the issue is on the list because there were no comments. If the
request had generated comments and had been rejected, I would have ignored
it. The whole purpose for making a formal proposal for the issue is to
encourage the discussion that did not happen the first time around.

So, do you agree or disgree with the proposal?

eric.

---

From: John Stracke <[email-masked]>
Date: Mon, 02 Oct 2000 15:27:15 -0400

> So, do you agree or disgree with the proposal?

I disagree, but not strongly.  I oppose it because I don't see any reason to do
it; if someone shows me a good use case, I might change my mind.

|eCal Corp.      |This is not a self-referential .signature.   |
[email-masked]|                                             |

---

From: Eric Busboom <[email-masked]>
Date: Mon, 2 Oct 2000 16:56:21 -0700 (PDT)

> it; if someone shows me a good use case, I might change my mind.

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. This isn't
a problem while the attendee accesses the attached file though the CUA,
but attachements tend to have a longer lifetime than the message they are
attached to.

If you send a document to me in a meeting proposal, I am likely to want to
keep the document for later reference, even after the CS has archived the
meeting proposal and it is no longer available to the CUA. ( At my last
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. If it does not have the same name as the the
Organizer gave it originally, then it will be impossible for the organizer
and the attendees to refer to the document out of band.

Adding a filename parameter to ATTACH would allow the document to keep the
same name among the organizer and all attendees. 

eric.

---

From: John Stracke <[email-masked]>
Date: Tue, 03 Oct 2000 10:04:50 -0400

Eric Busboom wrote:

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

> to need a sensible name.

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

|eCal Corp.      |I'm a .sig virus...and, boy, am I tired!     |

---

From: Eric Busboom <[email-masked]>
Date: Tue, 3 Oct 2000 09:25:32 -0700 (PDT)

On Tue, 3 Oct 2000, John Stracke wrote:

John, you said you didn't feel strongly about this issue :).

> attendee's system does not allow.

That's strictly true, but I don't know any filesystems that pervert
filenames so badly that they on longer contain any
information. "PROPOSA~.DOC" is still better than "X45GHHWD3.DAT"

>      server can also use the Content-Disposition: header.)

Sometimes the URL includes a filename, but it is becoming more common to
distribute URLs that point into a document management system (I've used
LiveLink) where the filename is either a node number or is deeply embedded
in the URL. 

Using Content-Disposition is a good way to do it, but only from the HTTP
Server's perspective. I think it just moves the responsibility for a
problem in the calendaring application to a system that is not controlled
by the calendaring spec. If you rely on Content-Disposition, sometimes you
will get it, and sometimes you won't. 

> implementations will make different choices, and you'll be right back where you

Clients will only make different choices if the specification does not
indicate which choice to make. 

If we add the FILE-NAME parameter, and specify how to resolve conflicts
between it, the Content-Disposition filename part, and the URL filename,
there should be no problems. To this end, I propose these rules: 

	1) Use the value of the FILE-NAME parameter
	2) If no FILE-NAME, use the value from Content-Disposition
	3) If no Content-Disposition, use the filename part of the URL
	4) If no file-name in URL ( it is a cgi or query string ) make
	something up.

Would this solve some of your concerns?

At my last company, it was very common to attach documents to Email, and
Eudora would put them in an attachments directory. I spent a fair amount
of time looking through that directory for documents that I had received
many months before. For these searches, the file names on the documents
were critical, so I think this is an important issue. 

eric.

---

From: John Stracke <[email-masked]>
Date: Tue, 03 Oct 2000 13:04:44 -0400

> John, you said you didn't feel strongly about this issue :).

Yeah, well...

> LiveLink) where the filename is either a node number or is deeply embedded

Mmm.  Such systems are arguably broken, because the documents being managed can't use
relative URLs to point to each other.  I have no particular remorse over not supporting
them.

> by the calendaring spec.

That's a *good* thing.  We should not be specifying features that already exist.

> indicate which choice to make.

Excuse me while I laugh hollowly.

Example of a category of client that will not follow the FILE-NAME spec: one that already
exists.

More generally, any time we have to introduce rules like this to clear up an ambiguity,
we can be certain that we're making a mistake.  It is better to make sure that it is not
possible to construct an ambiguous message.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If all the world's a stage, I want to operate|
[email-masked]|the trap door.                               |
\==============================================================/

---

From: Eric Busboom <[email-masked]>
Date: Tue, 3 Oct 2000 15:41:19 -0700 (PDT)

> possible to construct an ambiguous message.

You're right. I don't really like additional rules either. However, I
still think it is important to keep file names for attached data
consistent between organizers and attendees. If my suggestions will not
get us there, can you suggest something that will?

eric.

---

From: John Stracke <[email-masked]>
Date: Wed, 04 Oct 2000 12:25:33 -0400

> get us there, can you suggest something that will?

How about this:

   * 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.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |There are footprints on the moon. No feet, just|
[email-masked]|footprints.                                    |
\================================================================/