Re: MIME implementation documentation

Dave Crocker <dcrocker@brandenburg.com> Fri, 16 August 1996 06:50 UTC

Received: from ietf.org by ietf.org id aa03668; 16 Aug 96 2:50 EDT
Received: from cnri by ietf.org id aa03664; 16 Aug 96 2:50 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa02784; 16 Aug 96 2:50 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA24034; Fri, 16 Aug 1996 02:36:47 -0400
Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA24018 for <ietf-822@list.cren.net>; Fri, 16 Aug 1996 02:36:05 -0400
Received: from [205.214.160.106] (d76.netgate.net [205.214.160.112]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id XAA04137; Thu, 15 Aug 1996 23:42:00 -0700 (PDT)
Message-Id: <v03007822ae39be984785@[205.214.160.106]>
Date: Thu, 15 Aug 1996 23:01:25 -0700
X-Orig-Sender: owner-ietf-822@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: Dave Crocker <dcrocker@brandenburg.com>
To: John C Klensin <klensin@mail1.reston.mci.net>
Cc: Ned Freed <Ned.Freed@innosoft.com>, ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no
Subject: Re: MIME implementation documentation
In-Reply-To: <SIMEON.9608160005.D@white-box.mail1.reston.mci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Sender: dcrocker@ng.netgate.net
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

At 9:11 PM -0700 8/15/96, John C Klensin wrote:
> * Does "having an implementation" as IETF is prone to define
>it, imply that there are mechanisms to create specified relevant
>forms as well as reading them?

	create or otherwise map different data into different mime types.  yes.

> * Should one consider a particular MUA to be an
>"implementation" if it provides sufficient facility that a user
>can carefully hand-edit an outgoing message into conformity to a
>particular form or option?

	permit is different than require.  permit them to hand-edit, sure.
require it, e.g., in lieue of having the software, itself, do the work.  no
way.

>  * Do we consider that some form is "implemented" if, e.g., the
>"default if you don't recognize" option is taken?  For example,
>if few MUAs actually support receipt of multipart/alternative
>with tables of preferences rather than treating it as a variant
>on multipart/mixed, has "multipart/alternative" been
>"implemented"?  Following up the question above, if the only way

	no.

>And so on for any number of MIME features.
>
>Harald, I don't want to derail the train here, but I think I
>object to the idea of removing features that have not been
>independently implemented (whatever that means) and used only
>when a document comes up for full standard.  As I read the

	Yes, we need to audit functions not implemented and remove them
from the spec.  do you have any candidates for removal?

d/

--------------------
Dave Crocker                                            +1 408 246 8253
Brandenburg Consulting                             fax: +1 408 249 6205
675 Spruce Dr.                                 dcrocker@brandenburg.com
Sunnyvale CA 94086 USA                       http://www.brandenburg.com

Internet Mail Consortium               http://www.imc.org, info@imc.org