Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!MSU.EDU!08071TCP
From: 08071TCP@MSU.EDU (Doug Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: 'legal' protocol behavior (was: ARP question summary)
Message-ID: <9104120021.AA28730@ucbvax.Berkeley.EDU>
Date: 10 Apr 91 04:00:47 GMT
References: <ljm@ftp.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Doug Nelson <NELSON@msu.edu>
Organization: The Internet
Lines: 25

>The intent of my reply was to emphasise the importance of standard
>practice over RFC definition as a guide for implementors decisions
>as to what is 'legal'.  As with the MILSTDs (which are absolutely
>and completely correct except when they are wrong), an RFC should
>not be strictly followed by an implementor if this causes most
>existing hosts to lose.

I'll stand by my comments - in general, the RFCs ought to be the
definition.  Certainly there needs to be room to correct errors,
resolve ambiguities, extend protocols, and, in some cases, to make
allowance for an implementation error in a common implementation,
but such deviations ought to be strictly those that have been accepted
in the appropriate public forum (IETF, a mailing list, or whatever),
and ought to appear in the next revision of the spec.  The problems
with the MILSTDs have been well documented, as have other RFC errors
(such as those documented in the host requirements RFCs, for example).

I'm not willing to define "standard practice" as the way the first or
the most prevalent implementation does it, without some good justification
to go along with it.

And I'm not sure why we're dragging out this discussion, since the RFC
and "standard practice" are not in disagreement over the case in point! :->

Doug