Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!linus!decvax!genrad!grkermit!masscomp!clyde!burl!hou3c!solomon@wisc-crys.ARPA From: solomon@wisc-crys.ARPA Newsgroups: net.mail.headers Subject: Re: Several questions/comments on time zones Message-ID: <8402071810.AA14416@wisc-crys.ARPA> Date: Tue, 7-Feb-84 13:10:46 EST Article-I.D.: wisc-cry.8402071810.AA14416 Posted: Tue Feb 7 13:10:46 1984 Date-Received: Thu, 9-Feb-84 22:33:33 EST Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 50 To: milazzo@RICE-JANUS.ARPA Re: Date: Sun, 29 Jan 84 16:39:59 CST From: Paul MilazzoSubject: Re: Several questions/comments on time zones To: solomon@wisc-crys (Marvin Solomon) Cc: header-people@mit-mc Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice> "If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT) [...]." It is my understanding that RFC 733 did not invent the contents of a mail header; similar formats had been in use for some time. RFC 733 simply tried to make known (and perhaps official) the various de facto standards which had sprung up in the Internet community. Thus it became a sort of "conglomerate standard". I consider this effort a noble one, if perhaps incompletely successful. Paul G. Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX Several people have misuderstood various aspects of this comment, so I must have not made myself clear. First, I do understand the history of 733. One reason standards are hard to write it that you must make a choice between two unpleasent courses: On one hand you can wait until there are (incompatible) implementations and then try to come up with some sort of compromise that won't break too many existing programs. On the other hand you can try to write a spec for something that doesn't exist yet and run the risk of specifying something that is unimplementable. Perhaps I should have said that the choice of making headers human-readable was "unfortunate" rather than "a mistake". Several people have pointed out that while non-human-readable (binary) headers can only be read by programs, human-readable (text) headers can be read by both humans AND programs (using a little compiler technology) and thus would appear to be preferable. My point wasn't that parsing text headers is too hard, but rather that reading text headers is too easy, so that people tend to write mail-reading programs that simply show the headers to users. >From time to time, someone flames that "you wouldn't have [whatever your favorite problem is] if you had a decent mail-reading program". If binary headers were the standard, there would be no question but that a reasonable mail-reading program was required, and there would be much less confusion between trans-port level information (in both the envelope and header) and end-user information.