ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] FWD: [Technical Errata Reported] RFC5321 (5414)

2018-06-30 15:32:19
Anyone have comments on this?  I don't remember whether there
was a reason it was done the way it was or if that was just a
dumb ABNF error.

It was done this way to align it with RFC 822/RFC 5322. More below.

---------- Forwarded Message ----------
Date: Friday, June 29, 2018 15:30 -0700
From: RFC Errata System <rfc-editor(_at_)rfc-editor(_dot_)org>
To: john+smtp(_at_)jck(_dot_)com, iesg(_at_)ietf(_dot_)org
Cc: romer(_at_)apple(_dot_)com, rfc-editor(_at_)rfc-editor(_dot_)org
Subject: [Technical Errata Reported] RFC5321 (5414)

The following errata report has been submitted for RFC5321,
"Simple Mail Transfer Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5414

--------------------------------------
Type: Technical
Reported by: David Romerstein <romer(_at_)apple(_dot_)com>

Section: 4.1.2

Original Text
-------------
Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

Corrected Text
--------------
Quoted-string  = DQUOTE 1*QcontentSMTP DQUOTE

Notes
-----
As written, this allows for an email envelope recipient
(Forward-path) with a NULL value for the local part of their
address. This is a functional departure from similar wording in
the preceding RFC 821, which defines quoted-string in such a way
as to require at least one character that is not one of the
surrounding quotation marks.

It is not, however, a departure from RFC 822, which defines quoted-string 
as:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                 ;   quoted chars.

or RFC 5322, which defines it as:

quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

Now, I don't particularly care whether or not this particular construct is
allowed. What I do care about is that what's in RFC 5321 be consistent with
what's in RFC 5322. Inconsistencies between these specifications should be
avoided whenever possible, as they can cause operational problems when
some uses a construct allowed by one but not the other.

I also note that since this change was one to align the specifications,
it cannot be claimed to simply be an editing error that can be changed
by an erratum.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary,
please use "Reply All" to discuss whether it should be verified
or rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if
necessary.

IMO this erratum should be rejected.

                                Ned

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp