Re: Text/HTML in e-mail
Keith Moore <moore@cs.utk.edu> Tue, 28 November 1995 08:03 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09005; 28 Nov 95 3:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09001; 28 Nov 95 3:02 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa04220; 28 Nov 95 3:02 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA02252; Tue, 28 Nov 1995 02:07:07 -0500
Received: from wilma.cs.utk.edu (WILMA.CS.UTK.EDU [128.169.94.141]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA02226 for <ietf-822@list.cren.net>; Tue, 28 Nov 1995 02:06:34 -0500
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (cf v2.11c-UTK) id CAA14272; Tue, 28 Nov 1995 02:06:07 -0500
Message-Id: <199511280706.CAA14272@wilma.cs.utk.edu>
Date: Tue, 28 Nov 1995 02:06:01 -0500
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore <moore@cs.utk.edu>
To: "Dr. Mark K. Joseph" <izzy@aac.twg.com>
Cc: ietf-822@list.cren.net, moore@cs.utk.edu
Subject: Re: Text/HTML in e-mail
In-Reply-To: Your message of "Mon, 27 Nov 1995 17:00:03 PST." <19951128010003.izzy@aac.twg.com>
X-Sender: moore@cs.utk.edu
X-URI: http://www.cs.utk.edu/~moore/
X-Listprocessor-Version: 7.2 -- ListProcessor by CREN
> >b) within a multipart/realted, use content-disposition's filename to > >indicate the name of the file (relative to a temp directory). > >within a multipart/related, files would automatically be stored > >and sub-directories would be automatically created, but there > >would be some restrictions on the kinds of file names that would > >be allowed. > > This is fine but using "cid:" urls inside the HTML to point into > other message bodyparts should still be included as experimental. > We have already implemented this and its straight forward. To me > Keith's approach is the no short cut way of implementing links to other > body parts. It's not difficult to implement cid URLs if you have control over both the mail reader and the browser. It's very difficult to implement cid URLs if you don't have such control, and there is no standard for how MIME mail readers define the content-id to file name mapping for HTML browsers. I'm all for having cid URLs PROVIDED someone defines this interface. It should be relatively system independent and also be able to deal with nesting (multiple levels of multipart/related). > Also these "... some restrictions on the kinds of file names..." > sounds like a HACK, and smells like a HACK. Such an approach is not > required with the straight forward "cid:" approach. If you're going to let the sender specify a file name, and the recipient's mail reader is going to unconditionally/automatically store a file under that file name, you'd better have some well-established conventions for what sorts of names are legal. Obviously the receiving system is going to want to put those files in a directory of its own choosing, outlaw relative paths (e.g. "../../../../CONFIG.SYS"), etc, so we get much better interoperability if we establish rules for the kinds of things that senders can expect receivers to allow. As for whether it's a "HACK"...I prefer to think of it is using an interface that's already defined and implmented instead of creating a new one. This is the way the world works - water takes the path of least resistance when flowing downhill. If you don't want to flow down a certain path, it's going to take lots of work to divert it, so there'd better be a good reason why. I do prefer reference by content-id for aesthetic reasons, but I also recognize the value in letting body parts reference each other by filename. (as far as I know I was the first to propose both methods, so I like them both :) > >f) for the time being, we punt on [Content-]{Base,Location,UR{L,N,I}} > >for MIME email. We open a huge Pandora's box when we try to > >blur the line between "things that are included in an email message" > >and "things that are externally accessible". We already have one > >very similar Pandora's box with "the URN problem"; we don't need > >another one just yet, and we don't have to solve the general problem > >in order to provide a very useful facility. > > I don't know about other mail clients but with mine I can drag any HTML > page off of the net and mail it. Now most HTML pages I have seen have > relative URLs embedded in them. If I don't have a Content-Location header > to carry along with that HTML bodypart then the HTML can not be viewed > properly. This is a real problem and we are not just going to ignore it > now. I don't have a problem with this particular use of Content-Location (or Base, if you prefer). But let's call it "base", and let's make it a parameter to the html content-type rather than a general MIME header. This helps preserve the notion that it's an HTML-specific facility to support relative URLs, rather than the notion that it applies to any body part. I'm concerned that people will interpret Content-Location as "you can get the current copy of this file from this URL", which just encourages people to cache the URL->file binding without any kind of integrity, authenticity, or currency assurance. Keith
- Re: Text/HTML in e-mail Keith Moore