From owner-ietf-smtp(_at_)dimacs(_dot_)rutgers(_dot_)edu Thu Nov 21
08:01:36 1991
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu,
ietf-smtp(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: comment on the standards process
Date: Thu, 21 Nov 91 07:24:38 -0800
From: Paul A Vixie <vixie(_at_)pa(_dot_)dec(_dot_)com>
X-Mts: smtp
I found this while rereading the O`Malley/Peterson "TCP Externsions
Considered Harmful" paper. I consider it apropos to the 822 and smtp
working groups, as well as darkly humourous and very true.
Finally, there is a subtle problem introduced by the very freedom
provided by this approach. Specifically, being able to introduce a
new protocol often results in protocols that go far beyond the
basic needs of the situation. New protocols resemble Senate
appropriations bills; they tend to accumulate many amendments that
have nothing to do with the original problem. A good example of
this phenomena is the attempt to standardize VMTP [1] as the Inter-
net RPC protocol. While VMTP was a large protocol to begin with,
the closer it got to standardization the more features were added
until it essentially collapsed under its own weight. As we argue
below, new protocols should initially be minimal, and then evolve
as the situation dictates.
While not detracting from your application of this paragraph to your
own effort, I should mention that the quoted statement from the
"...Harmful" RFC is factually wrong (as are a number of other
statements in that RFC, but hey, I'm a card-carrying ACLU member!).
In fact, the accretion of features in VMTP resulted from the fact that
it was a vehicle for Dave Cheriton's academic research. He had lots of
ideas, and wanted to try them all out in the same environment. VMTP
never went through an IETF-like process, that could have pared it down
and cleaned it up. The situation with VMTP does illustrate the
possible difference between an Academic protocol and an Engineered
protocol.
Bob Braden