Keith Moore wrote:
first of all, it's really not a boundary condition - it's just one example
of an invalid address
It's a boundary condition as it's a unique case (zero content).
> second, your conclusion doesn't follow even if
it is a boundary condition - all that is necessary is that it not cause
any problems.
An MTA or MUA that does not handle [] well may indeed cause
problems. That might range from (multiple) DNS lookups of
garbage, or malformed DNS lookups to a program crash.
well, it's not like those thousands of existing implementations of email
software are going to change their implementation techniques just to
accomodate this case.
If it becomes a MUST NOT generate construct, damage can be
prevented even if an existing defective implementation of
a receiver does not change.
as for use of lex, I've tried it. it's not a good fit. 2822 syntax analysis
is somewhat context-dependent (is "Mon" a day or an atom?), good error
recovery is difficult, and you need to have the lexical analyzer recover from
common syntax errors (such as putting dot in a phrase) in situations where
look-ahead is required to disambiguate that kind of error from other
errors.
Having done both, I can confidently say that it's easier to write correct
C code to do the scanning than to write correct lex code to do it.
Having done both, I've come to the opposite conclusion, but
that's a bit off topic.
adding cruft to the standard (or to code) to detect cases which
never happen is not progress.
We're not talking about detection, but rather about relegating
a useless and potentially troublesome construct to MUST NOT
generate status.
progress is increasing the reliability
of mail delivery.
Is that relevant to the message format (as opposed to transport
methods and protocols)?