The IESG wrote:
<draft-klensin-rfc2821bis-06.txt> as a Draft Standard
The IESG plans to make a decision in the next few weeks,
and solicits final comments on this action.
To validate the syntax I've extracted all ABNF constructs
to a file, converting various 'Syntax: "verb" param CRLF'
contructs into 'verb = "verb" param CRLF' ABNF.
Then I added all direct and indirect imports from 4234bis
and 2822upd. There are three collisions where 2821bis
terms use the same name as similar 2822upd terms, I added
an "U" to these terms: local-part-U, domain-U, atom-U.
After that the output of Bill's parser started to make
sense, I canonicalized the spelling of some terms to get
rid of all warning, arriving at two ABNF syntax errors in
http://hmdmhdfmhdjmzdtjmzdtzktdkztdjz.googlepages.com/2821bis.ABNF.2
(2821bis.ABNF.1 is the version with different spellings)
Other issues (apart from two typos reported as errors):
1 - <ehlo-greet> permits any character other than CR and
LF. That covers NUL and NO-WS-CTL, I'm curious what
the interoperabilty test results will be for this
feature. Bill's parser is also unhappy with %d0, but
I didn't count this as error (it would be the third)
2 - <ehlo-param> excludes %d0-32 (NUL..SP), but permits
%d127, it's not obvious why DEL is no problem here.
3 - <A-d-l> contains 2119 keywords in an ABNF comment.
It's not obvious why source routes SHOULD NOT be
generated and SHOULD be ignored, 18 years after
they were deprecated. A MUST would be clearer if
the implementation report doesn't identify a 2821
MTA with a good reason to violate these SHOULDs.
4 - <esmtp-value> permits DEL for no obvious reason.
5 - <Argument> is by definition an 2821bis <Atom>. It
would be clearer to avoid this conflict with the
different 2822upd <atom> by using 1*atext directly:
<Dot-string>, <String>, <ID> , <Addtl-Link>, and
<Attdl-Protocol> are the 5 other <Atom> occurences.
6 - <Attdl-Protocol> and <Addtl-Link> are inconsistent,
I can imagine cases where keeping a "typo" could be
a good idea, but I don't see the necessity here.
7 - <Quoted-string> (not the same as the 2822upd term)
uses 2822upd <qcontent>. That pulls <qtext> with
<NO-WS-CTL>, a known 2822upd issue. It also pulls
<quoted-pair> with <obs-qp> = "\" (%d0 / LF / CR)
NUL, bare LF, bare CR, permitted whereever 2821bis
uses its <Quoted-string>. The interoperability
tests should explore if that really works anywhere.
8 - <General-address-literal> uses <dcontent> again with
<NO-WS-CTL>, and a quick and dirty test some months
ago published on the SMTP list already demonstrated
that this does not work. It's obscure why 2821bis
needs its own syntax for IPv6- and IPvFuture domain
literals, different from the full Internet STD 66.
<IPv6-addr> is impenetrable.
9 - <ID> permits a 2822upd <msg-id>, that pulls 2822upd
<obs-id-left> and <obs-id-right>. The reason why
2822upd obsoleted these constructs was that they're
not used in practice. Maybe 2821bis needs a general
"no 2822upd obs" clause, like the Netnews format RFC.
Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf