Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA07269; Sun, 21 Jan 1996 11:56:42 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.3); Sun, 21 Jan 1996 11:55:19 -0500 Received: from VM.SE.LSOFT.COM by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA07139; Sun, 21 Jan 1996 11:55:09 -0500 Message-Id: <199601211655.LAA07139@CS.UTK.EDU> Received: from VM.SE.LSOFT.COM by VM.SE.LSOFT.COM (IBM VM SMTP V2R3) with BSMTP id 0880; Sun, 21 Jan 96 11:54:49 EST Received: from VM.SE.LSOFT.COM (NJE origin ERIC@SEARN) by VM.SE.LSOFT.COM (LMail V1.2b/1.8b) with RFC822 id 8917; Sun, 21 Jan 1996 11:54:49 -0500 Date: Sun, 21 Jan 1996 11:43:25 EST From: Eric Thomas Subject: Re: The conservative and liberal commandment To: Keith Moore , Jacob Palme cc: ietf-drums In-Reply-To: Message of Sun, 21 Jan 1996 10:22:46 +0100 (MET) from Jacob Palme On Sun, 21 Jan 1996 10:22:46 +0100 (MET) Jacob Palme said: >If you think a standards document should specify (B) the protocol which >implementors should use in order to get well-working systems, then the >standard should specify two protocols, one for what you generate (more >limited) and another for what you accept (wider). Not necessarily. The real problem with Internet standards is that there is no certification process. Anyone can put a weekend's work on an FTP server, claim to have implement RFCxyz, and lose interest a few months later. Someone takes over and attempts to close the holes, and so forth. You know the story. You'll find many counter-examples in the real world - protocols that say "To do X you must send Y, period" and where people write code that does Y, period, and have it certified by an organization that makes sure they do Y, period. These products interoperate much, much better than Internet software does. And the specs are unambiguous, so any two engineers can quickly agree whether the standards says you should do Y or Y'. Eric