Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA28529; Tue, 30 May 1995 09:42:30 -0400 X-Resent-To: drums@CS.UTK.EDU ; Tue, 30 May 1995 09:42:29 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from domen.uninett.no by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA28520; Tue, 30 May 1995 09:42:25 -0400 Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <08744-0@domen.uninett.no>; Tue, 30 May 1995 15:42:18 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id PAA06159; Tue, 30 May 1995 15:42:15 +0200 Message-Id: <199505301342.PAA06159@dale.uninett.no> X-Mailer: exmh version 1.5.3 12/28/94 From: Harald.T.Alvestrand@uninett.no To: Eric Thomas cc: drums@CS.UTK.EDU Subject: Re: getting started In-reply-to: Your message of "Tue, 30 May 1995 13:48:57 +0200." <199505301214.IAA22394@CS.UTK.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 May 1995 15:42:14 +0200 Sender: hta@dale.uninett.no Eric, > All in all this business of having 10+ year old RFCs that get updated by > new RFCs from time to time is a big source of trouble. Implementors and > support people need a single document with all the edits applied, with a > clear mechanism to find out whether the document has been superseded. > Many companies are getting into the Internet, implementing 82x gateways > without prior experience. They'll get 822 and implement it, and then when > a customer whines that one of the change in 1123 isn't in the product, > they'll get confused or upset and this is generally counter productive. > If you put all the stuff in one document life will be much simpler for > everyone. I could not agree more - that is indeed why we chose to reject the writing of "yet another applicability statement" and decided to take the bull by the horns and rewrite the base documents. About the hostname stuff: I think the new docs should clearly identify that hostnames are legal DNS names, and leave it at that; it might copy a few of the rules for reference (like the charset limitations), but should otherwise refer to the DNS documents for the definition. (the under_score allowed by BIND *is* a bug, IMHO.) The legality of addresses like maryland.bitnet is a problem....let's think some more about that when we see where it belongs in the spec. Harald A