Re: MIME implementation documentation

Harald.T.Alvestrand@uninett.no Fri, 16 August 1996 07:25 UTC

Received: from ietf.org by ietf.org id aa05626; 16 Aug 96 3:25 EDT
Received: from cnri by ietf.org id aa05622; 16 Aug 96 3:25 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa03167; 16 Aug 96 3:25 EDT
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA24573; Fri, 16 Aug 1996 03:14:02 -0400
Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA24557 for <ietf-822@list.cren.net>; Fri, 16 Aug 1996 03:13:40 -0400
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <09551-0@domen.uninett.no>; Fri, 16 Aug 1996 09:13:33 +0200
Message-Id: <9548.840179611@domen.uninett.no>
Date: Fri, 16 Aug 1996 09:13:31 +0200
X-Orig-Sender: owner-ietf-822@list.cren.net
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: Harald.T.Alvestrand@uninett.no
To: John C Klensin <klensin@mail1.reston.mci.net>
Cc: Ned Freed <Ned.Freed@innosoft.com>, ietf-822@list.cren.net
Subject: Re: MIME implementation documentation
In-Reply-To: Your message of "Fri, 16 Aug 1996 00:11:05 EDT." <SIMEON.9608160005.D@white-box.mail1.reston.mci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Sender: Harald.T.Alvestrand@uninett.no
X-Mailer: exmh version 1.6.7 5/3/96
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

John,
valid question.
The relevant section of draft-ietf-poised95-std-proc-3-06.txt is
4.1.2  Draft Standard, which says:


   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

Interestingly enough, RFC 1602 is silent on the subject of features;
it was probably a needed clarification.

I think I will have one question here for POISSON: Where should we
document features that are NOT part of the Draft Standard, but nonetheless
remain valid applications of the standard in question, such as body parts
in MIME that were in the current standards, but do not themselves deserve
elevation to Draft?

That is, does "remove" mean "remove from specification", "move to a
document with another status", or "mark as not part of the standard"?

Anyway, you're right, and we need that documentation. The WG chair is
responsible for gathering it, but we don't have a WG chair.

Shucks, we don't even have a feature list!

The IESG vote is scheduled for next week. Do we have a volunteer to
do some work on this?
If not, I'm strongly tempted to declare that this document was already
at Draft, so we're just continuing a historical mistake.....

                Harald A