Re: MIME implementation documentation

Valdis.Kletnieks@vt.edu Fri, 23 August 1996 06:04 UTC

Received: from ietf.org by ietf.org id aa23900; 23 Aug 96 2:04 EDT
Received: from cnri by ietf.org id aa23896; 23 Aug 96 2:04 EDT
Received: from [204.153.50.13] by CNRI.Reston.VA.US id aa02251; 23 Aug 96 2:04 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA01821; Fri, 23 Aug 1996 01:42:49 -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 BAA01760 for <ietf-822@list.cren.net>; Fri, 23 Aug 1996 01:41:40 -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 BAA20968; Fri, 23 Aug 1996 01:41:36 -0400
Message-Id: <199608230541.BAA20968@black-ice.cc.vt.edu>
Date: Fri, 23 Aug 1996 01:41:36 -0400
X-Orig-Sender: owner-ietf-822@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: Valdis.Kletnieks@vt.edu
To: Harald.T.Alvestrand@uninett.no
Cc: ietf-822@list.cren.net
Subject: Re: MIME implementation documentation
In-Reply-To: Your message of "Thu, 22 Aug 1996 00:38:46 +0200." <7791.840667126@dale.uninett.no>
References: <7791.840667126@dale.uninett.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11232.840778895.1@black-ice.cc.vt.edu>
X-URL: http://black-ice.cc.vt.edu/~valdis/
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Thu, 22 Aug 1996 00:38:46 +0200, Harald.T.Alvestrand@uninett.no said:
> When it encounters a /parallel, it toggles the "serial" flag.
> That has the interesting property that if you have the structure
> 
> multipart/parallel
>   message/rfc822
>     multipart/mixed
>        image/gif
>        application/postscript
> 
> the parts of the INNER stuff are presented in parallel. Not exactly
> what I would call expected behaviour....but the support is there.

Ouch.  That's so unexpected it hurts.  ;)  I *thought* I smelled
something evil about what that 'serial' flag actually did, but
30 minutes of pondering the code failed to enlighten.  All I can
say in my defense is that it's hard to be an expectant father and
also understand convoluted C code. ;)

All the more basis for calling for multiparts/parallel to be moved
out to a seperate document - that way, those the "support" it via
downgrading to /mixed will still be technically in the right, and
those that intend to implement more will be able to hash THAT around
in experimental and proposed standard until we get something that
actually says what semantics we intended to have...

/Valdis (who will now go and sit on the sidelines for 2 weeks, while
he takes paternity leave - a long-awaited daughter finally showed up
last night ;)