--On Sunday, March 27, 2016 22:41 -0700 "Murray S. Kucherawy"
And if what you're really producing is regular expressions
that match anything that the ABNFs in the mail RFCs will
legitimately produce, you might want to do a standards track
document that explicitly updates those documents where those
ABNFs are listed.
That captures my concern about this effort. Based on prior
experience (including RFC RFC 3696 and even the effort to make
RFCs 2821 and 5321 internally consistent), it is _really_ easy
to express a requirement in two different ways and have them be
_almost_ the same. That is a problem because different people
will read different docs.
It seems to me that it would be much better to either do this as
an Informational document that is clearly identified as Sean's
opinion about regular expressions that impose the same
requirements as 5321/5322 but that those continue to control or
to do a standards-track document that contains both the regular
expressions and ABNF, makes clear which one is primary, and
updates the syntax requirements of the base specs.
Perhaps a BCP that recommends use of strings that are clearly a
proper subset of what the standard allows would be ok, but it
needs to be frightfully clear that it is a recommended subset,
not a requirement. For example, I've seen enough problems with
the two quoting conventions over the years that I'd be delighted
to see them eliminated entirely. On the other hand, I've seen
one attempt after another (outside the IETF) to reduce the rules
to simple regular expressions or equivalent that would forbid
subaddresses and/or the required syntax for conversions of
addresses from some other systems (the X.400 stuff stands out,
even though very few people care about it any more).
ietf-smtp mailing list