fair@dual.UUCP (Erik E. Fair) (10/29/84)
>> Date: Tue, 23-Oct-84 11:48:00 PDT >> From: Jacob_Palme_QZ@QZCOM.MAILNET >> >> FROM: Mark Crispin <MRC@SU-SCORE.ARPA> >> >> I swear, though, if after we finally get into full compliance >> with RFC 822 dates they change the syntax to something >> incompatible AGAIN, I'll get the %&#@! >> >> Surely they will. Do you not know that there is an international >> standard for calendar dates. Something like this, I believe: >> 1984-10-23-17.43.59 >> for todays date. <flame on> The rest of the world can go screw itself with X.400 (as they are apparently trying to) and we can pray that DoD will see the light and ignore them. Somehow, standards that are made by a committee of people who have never used or supported a large computer network (such as the ARPA INTERNET) strike me as ill conceived. For whatever glitches might be in the RFCs, they are the product of almost 15 years of research and practical experience, and should not be cavalierly discarded in favor of X.400. <flame off> internet forever, Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair Dual Systems Corporation, Berkeley, California
hagouel@ittvax.UUCP (Jack Hagouel) (10/29/84)
> For whatever glitches might be in the RFCs, they are the product of > almost 15 years of research and practical experience, and should not be > cavalierly discarded in favor of X.400. > > Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA Erik has a good point that RFCs have matured over years of both thinking and everyday use. Unfortunately, this does not guarantee standards that are useful to everybody. RFCs developed for a particular community and with some assumptions about the supporting environment. Early design decisions limit the amount and quality of modifications in later versions. Although I would hardly call myself an expert on the RFCs I find that the X.400 standards have a level of rationality rarely found in standards. This seems to have attracted a lot of support in the industry, a necessary ingredient for any proposal to become a standard. Could we think of them as a second generation standard? Jack Hagouel ...!ittvax!hagouel
schoff@cadtroy.UUCP (Martin Lee Schoffstall) (10/30/84)
> The rest of the world can go screw itself with X.400 (as they are > apparently trying to) and we can pray that DoD will see the light and > ignore them. Somehow, standards that are made by a committee of people > who have never used or supported a large computer network (such as the > ARPA INTERNET) strike me as ill conceived. What happens when you want to talk to rest of the world? There are other places in the world where people are doing interesting things. Then there is the question of why the DOD should be spending upteen billions of dollars on research in mail, networking etc.. when (or if) the commercial sector has a good answer. [Didn't you see the 60 minutes episode on the F20 Tigershark?] You are being a bit colonial in your belief that others haven't used or supported large computer networks. At the inception of the Arpanet others were also experimenting. Now there are a multitude of large X.25 networks, and yes even a internetwork of X.25 networks. > > For whatever glitches might be in the RFCs, they are the product of > almost 15 years of research and practical experience, and should not be > cavalierly discarded in favor of X.400. > One of the criticism that I have heard in the past is that the people who wrote the RFC's were RESEARCHERS, it was a real interesting research project and they even spent some time implementing 90% of the specification. But that other 10% was a bit hard and left as an excersize to the student while they go on to other interesting things, "We do research!" they would say. The problem was that the last 10% of the specification didn't hack it in the real world. If you don't want the DOD to cavalierly discard the RFC's (they won't), why don't you take the same tack and not cavalierly discard the work of other standards making bodies. marty schoffstall cadmus!schoff@seismo.ARPA {linus,seismo,bbncca,wivax}!cadmus!schoff