Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability.

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

Stephen and Tommy,

Sorry it has taken me so long to get to this, but, at least from
my perspective, your question (if I understand it correctly) has
some interesting answers.  These are my opinions only but it may
be worth noting that, although I helped with RFC 1123 and was
involved in other ways much earlier, I was dragged into the IETF
precisely to work on email protocols.

Inline below.

--On Tuesday, 07 July, 2020 02:14 +0100 Stephen Farrell
<[e-mail]> wrote:

> 
> Hi Brian,
> 
> (Maybe not directly a question for you but...)
> 
> On 06/07/2020 23:05, Brian E Carpenter wrote:
>> SMTP has been the classical example for many years, and I
>> suspect that RTCWEB might furnish another good example of
>> this problem before long.

> Do we have evidence as to the (good, bad or neutral) impact
> of the stately pace of the evolution of email standards-
> track  RFCs? I could imagine the net effect being overall
> positive or negative but am unsure which may be the case. I
> suspect it may be more likely that the actual impact is not
> correlated with RFC numbers at all, but that may also be
> wrong.

Once upon a time, it was a maxim of ARPANET and Internet
protocol design that things were to be kept simple, with a
minimum of options, alternate ways to do the same thing, and so
on.  Part of that was (or became) a deliberate contrast with a
well-known reference model and protocol suite that were so full
of options and variations that almost no one could implement
them and it was impossible to tell whether failure to
interoperate was a bug or the result of, e.g., difference
choices of options or profiles.  The designers of Internet email
had the added advantage of
experience with email systems that served users on a single host
and some that served a set of related hosts running the same
operating system software even before the mail command was
introduced into FTP. Even the envelope-header split came rather
last in the game.  The implication of that was that, by the time
RFCs 821 and 822 came along and the former was followed by RFc
974, they were based on years significant implementation,
deployment, and user experience, including experience with
gateways, _and_, by today's standards, they were still rather
simple protocols.  

The changes of the early 1990s were necessitated by new
requirements -- for multilingual and multimedia mail and for the
ability to do a number of things that the original protocols did
not facilitate doing in an interoperable way.. and to do so in a
way that would not break the existing widely-deployed
infrastructure.  Even then we made what may have been design
errors (or not).  For example, in allowing extensions we failed
to distinguish clearly between "I, the server, am offering these
extensions" and "I the server will not accept your mail unless
you support these extensions" and, in MIME, we specified a
header field of "MIME-version: 1.0" without any non-destructive
plan about what a different number might mean.  The next two
iterations were just consolidation of multiple specifications
and clarifications.  And the work now being contemplated (see
the "emailcore" BOF on the IETF 108 agenda) is intended to be
limited to clarifications and fixing errors and we just haven't
felt pressure to do it much earlier.  IMAP, for example, is
different -- more options, more commands, and more working
groups adding yet more options.

Now, contrast that situation with, e.g., SIP, HTTP/HTTPS, or
RTCweb and, well, it is an interesting contrast.

I hope everyone participating in this discussion has read Fred
Brooks on second system effects and perhaps thought a bit about
what it means to patterns of standards development.

    john