Re: Less is more

[Iljitsch van Beijnum <iljitsch@xxxxxxxxx>]

On 28-apr-04, at 22:59, Keith Moore wrote:

> > The precision of its specification is not the main issue. The main
> > issue is that it's a compromise between machine-readable and
> > human-readable

> I agree with that statement- but it's a direct result of the broader
> design choice to make email mesages be both machine-readable and
> human-readable.   Changing the date format without revisiting the 
> larger
> choice is probably wasted  effort.

If you look at MIME and/or HTML mail then the idea that mail is 
readable by humans without a mail client is mostly theorectical today.

I think there is middle ground between having a binary-only or a 
no-binary format. Since mail must both support readable text and opaque 
binary data neither extreme is attractive. I think it makes a lot of 
sense to, in addition to those fields that are binary by their nature, 
make some common fields binary if this has advantages. The date is a 
very good example. While having the date in binary means that even the 
lowest of low-level mail reading software must be able to decode it, 
writing such an application is trivial, and writing one that can 
actually do something useful with the dates it encounters in mail is 
just as trivial, which certainly isn't the case for the current format, 
and I expect this to be difficult for improved text-based formats too.

> Not so.  The amount of work in decoding an integer (say a UNIX-style
> time_t) to a date is approximately equal to the amount of work in
> parsing a RFC822 style date, and it's at least as easy to botch
> up the decoder as to botch the RFC 822 date parser.

Not having written any, I have a hard time believing this. Even 
something as trivial as finding the text between the whitespace is a 
huge pain without text parsing libaries.

> The amount of
> work in encoding an integer date from yyyy/mm/dd/hh/mm/ss form
> is more than the amount of work in encoding that same quantity
> in RFC 822 format - and it's harder to get that encoder right.

But I think most OS builders have gotten it right by now.

About timezones: note that these aren't inherently interesting: I don't 
care which timezone is configure on a server that happened to be on the 
path for a message. The reason the timezone (or rather: the local time 
for the sender) is interesting in mail is because it can be interesting 
to be able to see whether someone wrote something during business hours 
or late at night or whatever. Apart from this we only need UTC.