Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (3)

["Frank Ellermann" <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf