Re: Questions about RFCs 1494, 1495.

[Ned Freed <[e-mail]>]

> [I assume that <Internet-Drafts@CNRI> is not supposed to appear on replies.]

Correct.

> I still need to do a full read of the draft, but I'm please with what I've
> read so far.  I do have two general questions from my first breeze through.

Good.

> First, there seems to be some overlap between the new MIME content headers
> and the oft-hinted but as yet undocumented (?) Content-Disposition header.
> As you noted, the new headers are not restricted to FTBP mapping, and many
> of them fill a huge void in the current content parameters.  There should be
> only one solution.

The content-disposition header is in the process of being scaled back
drastically in functionality, in hopes that the result will be more usable. If
what's currently planned for it emerges, it would at most overlap the
Content-Pathname header, and probably not even that given the very different
semantics of the two. (One is a file name, the other is quite explicitly a full
path.)

I think this is a Good Thing. The Content-Disposition header was lost before in
a sea of debate and lack of consensus. It now seems poised to generate some
measure of succcess.

> Second, how do people feel about a large number of MIME headers with simple
> arguments vs. a small number of headers with compound arguments?  This is,
> something like this:

> 	Content-Type: application/ms-excel
> 	Content-Pathname: /home/csg/timecard.xlt
> 	Content-Permitted-Actions: Read
> 	Content-Last-Modification-Date: 6 Jun 1994 15:15:45 -0700
> 	Content-Creator: MSWD

> vs:

> 	Content-Type: application/ms-excel
> 	Content-Disposition: attachment;
> 	    pathname=/home/csg/timecard.xlt;
> 	    permitted-actions=read;
> 	    last-mod-date=6 Jun 1994 15:15:45 -0700;
> 	    creator=MSWD

> For a variety of reasons (some purely selfish) I prefer the second form.

While I can see some merit in the second form, I didn't use it for several
reasons:

(1) Everyone doing Internet has an RFC822 header parser around. These tend to
    be quite reliable. Parsing the interior of an extremely complex header, on
    the other hand, is something that's hard to get right. We've ample
    operational experience with this problem, and I prefer to break things
    down into multiple headers so at least the first level of discrimination
    can be done reliably. The headers defined in the FTBP draft are complex
    enough already without calling for them to be packed into a couple of
    mega-headers.

(2) The syntax of both Content-Type and Content-Disposition is
    unsuitable for repeated attributes. This forces the use of separate headers
    for these attributes anyway. Since this choice is forced on us for at least
    some attributes, using another approach for others is somewhat
    inconsistent.

(3) The semantics of Content-Disposition don't seem to mesh well with some
    of the things FTBP carries around. And unfortunately, some of the places
    where the semantics do mesh are ones where the syntaxes collide.

(4) I tried it using the second form first in my original draft. It was truly
    horrible!

(5) The Internet succeeds by division of labor. Were we to couple the FTBP work
    with Content-Disposition, we end up with a dependency where a failure of
    consensus on Content-Disposition could cause FTBP to fail as well. I have
    no problem with either of them failing on the basis of merit, but not
    because of the other's merit.

(5) is the real killer, in my opinion, and I don't see an easy way around it.
The prior history of Content-Disposition doesn't inspire me with confidence,
either.

				Ned