On Fri, 18 Feb 2000, Jon Ribbens wrote:

Not a particularly good rule anyway, if you ask me. (Which you didn't.)

It should be "be conservative in what you send, and conservative in what you accept".

Actually, my REAL opinion on this (based on several years of process control - which MUST be reliable lest someone get killed) is this: "Be conservative in what you send, and don't be surprised if someone else sends you something you don't expect, and be prepared to deal with it". or, in the process control world: "Be very consistent (safe) in what you do, even when presented with bogus data." I think that was really the intent of the robustness principle. But lest we get in to an argument and reduce the S/N ratio of nanog (if that is possible)... The real point of my message was this: Using RFC1918 space in a net-visible manner is being liberal in what you send and being liberal in what you send is not a good idea. ESPECIALLY when people are being conservative in what they accept. Off-topic note: It seemed like every chuck of process control code I wrote ended up being something like "If it fails this way do this, if it fails this other way, do this, if it fails in yet another bizzare way, do this, and, if by chance it actually worked, do this." 90% of the code was dealing with failure modes. From my experience CGI scripting/network programming tends to be about the same. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------