Re: MIME implementation documentation

Chris Newman <Chris.Newman@innosoft.com> Mon, 19 August 1996 23:43 UTC

Received: from ietf.org by ietf.org id aa23918; 19 Aug 96 19:43 EDT
Received: from cnri by ietf.org id aa23913; 19 Aug 96 19:43 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa21612; 19 Aug 96 19:43 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA21375; Mon, 19 Aug 1996 19:37:23 -0400
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id TAA21357 for <ietf-822@list.cren.net>; Mon, 19 Aug 1996 19:37:00 -0400
Received: from elbonia.innosoft.com ("port 34319"@ELBONIA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8GT837H1O8Y53VT@INNOSOFT.COM>; Mon, 19 Aug 1996 16:35:59 -0700 (PDT)
Message-Id: <Pine.SOL.3.91.960819153244.4770A-100000@elbonia.innosoft.com>
Date: Mon, 19 Aug 1996 16:36:15 -0700 (PDT)
X-Orig-Sender: owner-ietf-822@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: Chris Newman <Chris.Newman@innosoft.com>
To: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu
Subject: Re: MIME implementation documentation
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

I believe Pine and IMAP4 servers (I know of at least 4 independant 
implementations) are examples of handling nested multiparts on the client 
side.  Pine numbers the parts in such a way that the nested structure is 
clearly visible to the user.  IMAP4 parses the MIME message into a 
hierarchical structure which preserves the nested represntation.

I am curious what will happen if the IESG rules that there isn't enough 
support for generation of arbitrary nested multiparts through a 
reasonable user interface.  The nesting structure of MIME is widely used, 
although it is usually used for special purpose sub-structure 
(multipart/appledouble, message/rfc822, multipart/security, etc) rather 
than general purpose hierarchy (although there seems to be plenty of 
support for displaying general purpose hierarchy in messages).

As for multipart/parallel, it does not seem to be widely implemented, nor 
does it seem to be an important part of the spec.  One reasonable option 
would be to remove the text from the spec and place it in the IANA media 
type registry.