From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: two minor points
Date: 13 Aug 92 03:24:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Aug 1992 20:24:41 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNI9F8OMB694E2YG@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I'm sorry, but I stand by my previous statements 100%. I used the word
"recommended" here with great care. I never said this was standardized.
A "recommended standard" is very very different from a simple recommendation.

The fact of the matter is that despite the fact that this document is not
standards-track it was nevertheless reviewed by the working group. I don't
know what you mean by "no discussion" -- I saw considerable discussion and
large amounts of consensus behind this document. In my opinion this was far
more than sufficient to call the document "recommended".

You can view this as the effort as the product of personal opinion and
not part of the group effort if you like, but let me assure you that the
implementors I've talked to don't take this view at all. There are many
reasons for this: (1) The document is written by one of the MIME coauthors
(not me) and thus carries considerable weight, (2) The document was a product
of the working group in large part (whether you think so or not), (3) The
suggestions made by the document are without exception extremely reasonable
and mostly obvious, (4) The document gives many suggestions which actually
will speed the deployment and implementation of MIME, (5) Many of the
things in this document were put there precisely because they were issues that
implementors thought should be addressed by MIME, (6) Many of the things
in this document were put there because people of influence with big e-mail
problems wanted them solved.

I think the choice to make this document an informational one was and is sound,
but it is a hell of a lot more than the ramblings of a random individual. In
the final analysis, a lot of people (implementors too) think that an RFC of
any sort is a standard, and if they like it they will implement it.

There is ample historical precedence for this, incidentally. Craig Partridge's
RFC on how to use the DNS when delivering mail is an informational document.
However, if it weren't for the fact that every mail system of substance on
the Internet implemented this "personal opinion", there wouldn't be much
successful transmission of mail these days. Try implementing mail strictly
from the RFCs that describe the DNS's function and use and see how far you
get (I've done this so I know more than I care to about it). The RFC number
is 974 in case you care to have a look.

				Ned

P.S. I don't have a problem with this, by the way. Informational RFCs of this
sort are an absolutely vital part of the process by which we implement
Internet standards. They serve roughly the same purpose at all those annexes
in OSI documents that "aren't part of the standard" do. You ignore these at
your peril, just as you ignore certain informational RFCs at your peril.