Subject: [usefor] Issue with ABNF grammar in RFC 5536

From: Julien ÉLIE <[email-masked]>
Date: Mon, 3 Jul 2017 22:23:45 +0200

Hi all,

Paul Kyzivat noticed in the IETF Gen-ART mailing-list
   https://www.ietf.org/mail-archive/web/gen-art/current/msg14921.html
that there is an issue in the ABNF of RFC 5536 (USEFOR).

RFC 5536 defines the following extension:

    fields          =/ *( approved /
                          archive /
                          control /
                          distribution /
                          expires /
                          followup-to /
                          injection-date /
                          injection-info /
                          lines /
                          newsgroups /
                          organization /
                          path /
                          summary /
                          supersedes /
                          user-agent /
                          xref )

to the following element in RFC 5322:

    fields          =   *(trace
                          *optional-field /
                          *(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                        *(orig-date /
                        from /
                        sender /
                        reply-to /
                        to /
                        cc /
                        bcc /
                        message-id /
                        in-reply-to /
                        references /
                        subject /
                        comments /
                        keywords /
                        optional-field)

and a message is defined this way:

    message         =   (fields / obs-fields)
                        [CRLF body]

It appears that the extension done in RFC 5536 is wrong because of how 
"fields" is constructed in RFC 5322; as a matter of fact, (*a *b) in RFC 
5322 is extended to (*a *b) / *c in RFC 5536 whereas (*a *b *c) was wanted.

I believe an erratum should be filled to RFC 5536.  Maybe by just 
changing the wording in Section 3:

    The following news header fields extend those defined in Section 3.6
    of [RFC5322]:

      fields        =/ *( approved /
                          archive /
                          control /
                          distribution /
                          expires /
                          followup-to /
                          injection-date /
                          injection-info /
                          lines /
                          newsgroups /
                          organization /
                          path /
                          summary /
                          supersedes /
                          user-agent /
                          xref )

to:

    The following news header fields are defined by this document:

      news-fields    =    approved /
                          archive /
                          control /
                          distribution /
                          expires /
                          followup-to /
                          injection-date /
                          injection-info /
                          lines /
                          newsgroups /
                          organization /
                          path /
                          summary /
                          supersedes /
                          user-agent /
                          xref

    The definition of message in Section 3.5 of [RFC5322] is changed to:

      message       =   *(fields / obs-fields / news-fields)
                        [CRLF body]

Any better idea of fix in RFC 5536?

-- 
Julien ÉLIE

« You know what I did before I married?  Anything I wanted to. »

---

From: Michael Bäuerle <[email-masked]>
Date: Fri, 7 Jul 2017 18:59:14 +0200

> to the following element in RFC 5322:

Hi Julien,

there is Erratum 2950 (Status: Held for Document Update) that specify
it like this:

   fields          =   *(trace
                         *optional-field /
                         1*(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                       *(orig-date /
                       from /
                       sender /
                       reply-to /
                       to /
                       cc /
                       bcc /
                       message-id /
                       in-reply-to /
                       references /
                       subject /
                       comments /
                       keywords /
                       optional-field)

>       message       =   *(fields / obs-fields / news-fields)
                          ^
>                         [CRLF body]

Wouldn't this asterisk introduce the same "infinite loop of empty
strings" situation as in the erratum noted above?

-- 
Michael Bäuerle

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 10 Jul 2017 21:46:49 +0200

Hi Michael,

> strings" situation as in the erratum noted above?

As "fields" in RFC 5322 amended with erratum 2950 no longer has an 
infinite loop of empty strings, *(fields / obs-fields / news-fields) 
also do not have, don't it?

Note that using 1*(fields / obs-fields / news-fields) is also fine 
because headers are not empty.

I once thought about something like original (fields / obs-fields) 
extended with *news-fields.  The issue is that "fields" and 
"news-fields" are a/ mixed and b/ Netnews specific header fields do not 
appear after all mail header fields.

-- 
Julien ÉLIE

« – Chef ! On vient !
   – On se met en carré ?
   – Non ! En bosquet ! » (Astérix)

---

From: Michael Bäuerle <[email-masked]>
Date: Thu, 13 Jul 2017 18:54:49 +0200

Julien ÉLIE wrote:
> Michael Bäuerle wrote:

Agreed. Looking at RFC 5322 again I'm no longer sure that there really
was an infinite loop even without erratum 2950 applied.
For an infinite loop of empty strings something like this is required:

   *(*a)  ; Can result in ∞(0a)

Looking at:

   *(trace
     *optional-field /
     *(resent-date /
       resent-from /
       resent-sender /
       resent-to /
       resent-cc /
       resent-bcc /
       resent-msg-id))

The second and third repetition operators are not nested (alternatives)
but the result can reduce to:

   *(trace)

if both of them use zero repetitions. Note that there is no slash after
trace and trace must contain at least one "Received" header field:

   trace  =   [return]
              1*received

Therefore the content in the outer parenthesis can not be empty.

Have I overlooked/misunderstood something?
Can somebody show an example how to create an infinite loop of empty
strings from the original syntax?

-- 
Michael Bäuerle