Re: The TEXT/HTML Content Type in e-mail

Ed Levinson <elevinso@accurate.com> Thu, 02 November 1995 19:11 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18932; 2 Nov 95 14:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18928; 2 Nov 95 14:11 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa16195; 2 Nov 95 14:11 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA20857; Thu, 2 Nov 1995 13:25:13 -0500
Received: from Princeton.EDU (root@Princeton.EDU [128.112.128.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA19597 for <ietf-822@list.cren.net>; Thu, 2 Nov 1995 13:05:42 -0500
Received: from acupain.UUCP by Princeton.EDU (5.65b/2.122/princeton) id AA14357; Thu, 2 Nov 95 12:54:54 -0500
Received: by Accurate.COM (4.1/SMI-4.0) id AA04498; Thu, 2 Nov 95 12:34:52 EST
Message-Id: <9511021734.AA04498@Accurate.COM>
Date: Thu, 02 Nov 1995 12:33:57 -0500
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ed Levinson <elevinso@accurate.com>
To: Jacob Palme <jpalme@dsv.su.se>
Cc: ietf-822@list.cren.net, Web4Groups Technical Mailing List <ratatech@dsv.su.se>, ietf-types@uninett.no, elevinso@accurate.com
Subject: Re: The TEXT/HTML Content Type in e-mail
In-Reply-To: Your message of "Thu, 02 Nov 1995 15:52:15 +0100." <Pine.SUN.3.91.951102135017.13937P-100000@ester.dsv.su.se>
X-Org-Addr: 2 Industrial Way
X-Org-Addr: Eatontown, NJ 07724
X-Org-Misc: 1.908.389.5550 (phone) 1.908.389.5556 (fax)
X-Mailer: MH 6.8
X-Listprocessor-Version: 7.2 -- ListProcessor by CREN

There are several issues mixed together in Jacob's message all of
which need to be addressed.  First, though, let's separate them out.

	1)  References to existing URLs (i.e. available from HTTP
	    servers) in WebEmail text/html

	2)  The appropriate use of the cid (and mid) urls

	3)  Providing for alternate representations

The first two seem straight forward and I'll address them here.  The
third deserves its own thread.

Naturally text/html entities could refer to any URL, but what if you
want to include it in the message.  In that case the referred to entities
should be made available to the Web browser / MIME helper application.
IMO, through the browser's cache.  Jacob suggests this behaviour.

The mechanism for providing a server location for those Web elements
included in the MIME message could be Content-Location as Jacob
proposed or Content-Disposition as Keith suggested.  I prefer the
latter and would have the file name be a URL.  Does anything prevent
that?  Rfc 1806, Content-Disposition says 

	The receiving MUA should not respect any directory path
	information ....  The filename should be treated as a terminal
	component only.

In theory a URL is opaque and thus qualifies as a "terminal component".
In reality we all recognize the details for what they are.

Keith points out that the cid/mid urls provide for private messages
that work as web pages.  He points out that at some point the referred
to entities need to be reduced to filenames on the recipient's system.
That implies the main page, the text/html entity, must be edited to
convert the cid/mid to file names.  Unless, of course, the browser can
process the MIME message.

In both these cases Multipart/Related provides some useful service in
collecting the Web page elements into a single entity and providing a
processing model.  In particular, draft-ietf-mimesgml-related-03
posits a Receiving Agent (RA) that can perform the services of moving
the included, but web served, images into the browser's cache or,
if needed, transforming the cid: urls in the text/html into file: ones.

Dealing with alternates, however, thread of another color.

Best.../Ed