08071TCP@MSU.EDU (Doug Nelson) (04/10/91)
>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
ljm@FTP.COM (leo j mclaughlin iii) (04/11/91)
>>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'.... > >I'll stand by my comments - in general, the RFCs ought to be the >definition. Certainly there needs to be room to correct errors... >but such deviations ought to be strictly those that have been accepted >in the appropriate public forum (IETF, a mailing list, or whatever)... > >...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. > I just get tired of having to debug yet another implementation which was written by someone going off in a corner and developing communications software 'according to the RFC' when the RFC deviates from existing practice. I know a number of TCPs which were written by this method (I'll name names privately if you'ld like) which don't actually work all that well. As for acceptance in a public forum, the last IETF saw yet another rousing cheer for considering conformance testing, much less simple belief in conformance to a document, to be worthless in judging if an implementation is ready to be distributed to the world at large. The point being that it is only by conducting interoperability testing with as many different implementations as possible can the quality or 'legality' of an internetworking product be judged. And that the ability to quote a section from a MILSTD or RFC is insufficent cause to loose a noninteroperable implementation on poor users. enjoy, leo j mclaughlin iii ljm@ftp.com
donp@na.excelan.com (don provan) (04/13/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <9104110553.AA03082@ftp.com> Date: Thu, 11 Apr 1991 22:04:41 GMT In article <9104110553.AA03082@ftp.com> ljm@ftp.com writes: >I just get tired of having to debug yet another implementation which was >written by someone going off in a corner and developing communications >software 'according to the RFC' when the RFC deviates from existing practice. On the other hand, i got a little tired of people measuring protocol correctness by whether it interoperated with BSD 4.2. >The point being that it is only by conducting interoperability testing with >as many different implementations as possible can the quality or 'legality' >of an internetworking product be judged. Interoperability testing is certainly important, but a failure to ineroperate still requires a way to determine which implementation is in error, and the specs provide a mechanism for making that determination. Depending on interoperability testing only is exactly what got the TCP/IP community into the "BSD mess" that we're finally leaving behind us. I, for one, would rather not see that era repeated. don provan donp@novell.com