IETF Logo Mail Archive

Re: MIME implementation documentation

Valdis.Kletnieks@vt.edu Wed, 21 August 1996 16:12 UTC

Received: from ietf.org by ietf.org id aa19661; 21 Aug 96 12:12 EDT
Received: from cnri by ietf.org id aa19657; 21 Aug 96 12:12 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa12291; 21 Aug 96 12:12 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA27209; Wed, 21 Aug 1996 11:55:17 -0400
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA27115 for <ietf-822@list.cren.net>; Wed, 21 Aug 1996 11:54:52 -0400
Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id LAA18186; Wed, 21 Aug 1996 11:54:27 -0400
Message-Id: <199608211554.LAA18186@black-ice.cc.vt.edu>
Date: Wed, 21 Aug 1996 11:54:26 -0400
X-Orig-Sender: owner-ietf-822@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: Valdis.Kletnieks@vt.edu
To: Ned Freed <Ned.Freed@innosoft.com>
Cc: Dave Crocker <dcrocker@brandenburg.com>, ietf-822@list.cren.net
Subject: Re: MIME implementation documentation
In-Reply-To: Your message of "Tue, 20 Aug 1996 22:18:53 PDT." <01I8IJY8NFFU8Y5617@INNOSOFT.COM>
References: <SIMEON.9608161323.A@muahost.mail1.reston.mci.net> <01I8CJGV6XIU8Y507E@INNOSOFT.COM> <01I8IJY8NFFU8Y5617@INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="===_-1_Wed_Aug_21_11:54:25_EDT_1996"; micalc=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
X-Mailer: exmh version 1.6.7 5/3/96
X-Url: http://black-ice.cc.vt.edu/~valdis/
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Tue, 20 Aug 1996 22:18:53 PDT, Ned Freed said:
> No it isn't. As I previously stated in an earlier message, we had multiple
> interoperable implementations of multipart/parallel in 1990, long before the
> original MIME RFC came out. Specifically, we had Metamail and MHN. I know for a
> fact that Metamail support for multipart/parallel works because I have used it
> and I just confirmed with Marshall Rose that MHN did and does support this
> construct.

Ned:

Unfortunately, I'm looking at the source for MHN right now, and unless I'm
more caffeine-deficient than I thought, it appears that multipart/parallel
is basically punted to multipart/mixed.  Specifically, in function
user_content(), it basically says "if it's /parallel, pretend it's /mixed"
(near line 6122).

Since, as I remember it, MIME-conformant agents are required to punt
unknown multipart/bogon's to /mixed, I don't see how this *really* qualifies
as "full" support.

Do any implementations do anything for /parallel *ABOVE AND BEYOND* treating
it as /mixed?
-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech

v2.8.7 | Report a Bug | By Email