From kragen@dnaco.net Wed Aug 26 11:36:53 1998 Date: Wed, 26 Aug 1998 11:36:51 -0400 (EDT) From: Kragen To: systalk@ml.org Subject: Re: [ST] I need help with reverse DNS lookups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Keywords: X-UID: 1452 Status: O X-Status: On Tue, 25 Aug 1998, George Bonser wrote: > Let me say it again. RFC's don't really MEAN anything. The RFC's say you > should look for mail servers using WKS records, too, but nobody ever has. Actually, the use of WKS records at all, in any context, is discouraged in the Host Requirements RFCs (which are also official Internet standards.) "Let me say it again. There are RFCs that are jokes, RFCs that are informational, and RFCs that are official Internet standards. Just because a document is an RFC doesn't mean you ought to follow it -- but it doesn't mean it's meaningless, either. Some RFCs ought to be followed, such as the official standards." > In many cases, RFC's are attemtping to document a protocol or method AFTER > the fact. They are simply reporting how it is currently being done by most > people. Indeed -- they are the best kind of standard: they document things that are guaranteed to be implementable, because they've been implemented, they document the range you must stay within to be compatible with common non-conforming implementations, and they describe the best way to do things. > There are several kinds of RFC; Proposed Standard, Adopted > Standard, Best Current Practice, etc. As far as I know there is still not > an RFC properly documenting http or PPP. HTTP: RFCs 1945 and 2068, May 1996 and January 1997 -- and 2069, 2109, and 2145 tell you about extensions and clarifications. PPP: 1661, 2153, July 1994, May 1997 -- and numerous others, like 1662, 1663, 1717, 1762, 1763, 1764, 1841, 1967, 1968, 1973, 1989, 1979, 1977, 2125, 2023, and 1994, tell you about extensions, how to tunnel various other protocols over PPP, etc. What do you mean by "properly"? > RFC's need to be taken with more than a few grains of salt. Just because > you claim RFC compliance means nothing if everyone else does it another > way. Of course, if everyone fails to interoperate with your RFC-compliant application, you should try to be more interoperable. Most RFCs document current practice better than that. Some RFCs (for example, RFC 1882) need to be taken with a scoop of salt or so. Others are better taken with dry white wine, or followed to the letter. > The RFC's say you MUST accept email even if the reverse DNS does not > match the HELO but nobody does. No, the RFCs do not say that. (At least, RFC 821 doesn't say that.) But, in fact, people do regularly accept mail from my machine (HELO gentle.dyn.ml.org, reverse DNS kragen.dnaco.net). > You can cling to the RFC and find yourself > alone while the rest of the world does things a different way. I am not aware of any cases of this happening. The Robustness Principle ("Be liberal in what you accept, and conservative in what you send"), codified in several of the official standards RFCs, prohibits it, anyway. > ANYONE can write an RFC. That was the case at one time. It is no longer the case. Read djb's "Submitting an RFC: A Case Study". > It does not mean that anyone will abide by it. > RFC1123 that clarifies 821 and 822 for example is nearly 10 years old, > obsolete, outdated, and few abide by it any longer. This is simply incorrect. Essentially all mail programs conform to RFC821 to the letter; those that do not conform have compatibility problems with other mail programs on the Internet, and those that do conform (while allowing laxity in conformity from other mail programs) have no such problems. If it becomes the case that few abide by an official Internet standard any more, then I'm sure the ISOC will issue a new standard so that authors of new software will be able to write interoperable code. > THe internet changes faster than the RFC's do. FORGET RFC's. It's true that the Internet changes very fast, in some ways. But there are a *lot* of old machines out there running Internet software that was written five, ten, fifteen years ago. The machine I'm writing this on still thinks that the local network's broadcast address has a host number of all zeroes, despite the fact that this was cleared up about fifteen years ago. Until last year, lots of people were running versions of Sendmail that were ten years old. Lots of people are still running NCSA httpd, which hasn't been updated since 1994. If you want to be interoperable, reading RFCs is a really good idea. If you don't want to be interoperable, the Internet is the wrong place for you. > If 99% of > applications will work with something and the 1% that does not claims they > are RFC compliant, tell them to clean up their act and get real-world > compliant. Of course. Can you cite an example? > That is my problem with authors of some software that dig into some > obscure corner of a functionally obsolete RFC and code in some feature > that breaks half the clients out there on the net and then claim the > client is broken because they are in accordance with the RFC. It's > baloney. Breaking half the clients on the net is acceptable, although not nearly as good as being able to interoperate correctly with non-compliant clients. > You can find anything you want SOMEWHERE in an RFC. True, but not in official Internet standard RFCs. Kragen -- Kragen Sitaker We are forming cells within a global brain and we are excited that we might start to think collectively. What becomes of us still hangs crucially on how we think individually. -- Tim Berners-Lee, inventor of the Web