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 Milazzo 
	Subject:  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.