Re: MIME implementation documentation

[John C Klensin <[e-mail]>]

On Thu, 15 Aug 1996 08:17:25 -0700 (PDT)  Ned Freed 
<[e-mail]> wrote:
> > just as a formality, I'll need someone to stand up and say that they have
> > products implementing MIME according to the new documents.
> 
> Our PMDF MAIL user agent implements MIME per the specification. (So does the
> version of Pine we ship, but it is not really any different than UW Pine in
> this regard.)

Consider these philosophical questions, rather than a complaint 
or objection, but:

 * 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?

 * 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?

  * 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 
to create a multipart/alternative object in some MUA is to 
construct a multipart/mixed message, read the message (including 
all header and boundary information) into an editor and then 
change "/mixed" to "/alternative", has multipart/alternative 
been implemented?

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 
Poised docs, that step has to be taken at Draft.  More important 
than the procedural issue, unless something comes toward full 
standard with very wide (and clear) community consensus about 
what is worthwhile and what isn't, an attempt to remove a 
feature at that stage could easily, and legitimately, lead to a 
claim that the standard without it has not been proven in the 
marketplace to be consistent and of adequate interest/ 
importance to the community.

IMO, the bugs, and the questions about what functionality should 
be there and what should not, really ought to get worked out 
in going to Draft.

    john