On Wed, 5 May 2004 00:24, Paul Smith wrote:
Well, it's trivial to generate the ISO format. Validating it may be
harder(but certainly not harder than the RFC822 form AFAICS), but,
how often does it need to be validated and not converted to
human-readable..
That depends on how strict you want the overall protocol to be. If the
only time a date field is used is when it's displayed to the user,
then it's possible for all intervening MTAs to ignore that data. That
being so, the intervening MTAs will, technically, be forwarding
malformed data (and propagating a protocol violation) when the
incoming data is malformed. If the MTAs parse it (just to check
syntactic validity), then the error can be detected at the outset.
It's debatable as to which of these scenarios is preferable.
mail-ng needs to make a clear distinction between submission and
relaying. the job of a relay is to preserve the message, not to fix it.
the content of a message is opaque to the relay.
the job of the submission agent is to authenticate the source (for some
meaning of "authenticate", to reject or fix invalid messages (and
provide feedback to the user that his MUA is broken) and submit
valid messages to the email transport system.
If you're going to insist on UTC, you ought to do a proper job of
implementing it, right?
right. I can't see any justification for using epoch-offset-style
dates. MUAs need to compare dates and display dates and they need to
display consistent dates between one MUA and another; they generally
don't need to compute precise deltas between dates. display of ISO
dates is trivial and you can compare and display ISO dates without
dealing with leap seconds.
--
Regime change 2004 - better late than never.