If that field occurred in an actual message generated by an actual
MUA I'd claim it was a programmer error even if it was syntactically
valid:) Anyone who put that in a shipping product ought to be
sacked.
And what about the protocol designer?
with 24 years' hindsight, the baroqueness of the message format is hard
to justify.
If a program can't parse Frode's field, it can't parse the RFC822
date> field syntax as specified.
True, but it could quite possibly parse 99.999% of the dates that
occur in actual use, including dates that aren't valid - at which
point the inability to parse dates is insignificant in comparison to
failures that
are due to other problems. If you're concerned about reliability
you care about how well it works in actual use, not whether it
handles really obscure corner cases. (security concerns are an
exception - since crackers specifically look for corner cases.)
This sounds like a decent pragmatic approach to protocols which are so
complex or ambiguously defined that writing code that handles all
possible permutations is infeasible. However, when building a new
protocol it makes sense to create it such that the number of possible
permutations is small enough that it's possible to fully implement and
test them all.
well, a version of the current date field that didn't allow comments
in the middle of a date, and that required numeric timezone offsets,
would come fairly close.
but I'm not really arguing (much) about how dates should be represented
- I'm arguing about how we should justify design decisions.
An interesting question is whether it's better to implement a binary
date format as a timestamp or a concatnation of
year/month/day/hour/second fields. The advantage of timestamps is it
makes date comparisons easy and there is no ambiguity as every
possible value is a valid date/time.
comparisons of dates are easy either way. also it's certainly
possible to specify a "separate fields" format in such a way that
the potential for ambiguities is minimized. you might still have
the possibility of feb 29 in a year that isn't a leap year or :60
for a second that isn't a leap second, but those cases will be rare.
Add to that that a binary format with explicit length values is much
faster to parse (especially on disk where you can seek over large
uninteresting parts)
binary with explicit length is not -inherently- faster to parse,
though it's certainly possible to design a format that is fast to
parse. somehow I don't think that's an overriding consideration
though. I'm more concerned with robustness - including
minimizing implementation errors.
--
Regime change 2004 - better late than never.