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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf