Re: [yam] [Technical Errata Reported] RFC6152 (5646) {dkim-fail}

[Ned Freed <[e-mail]>]

Agreed; the current text is correct and this should be rejected.

				Ned

> Please reject.

> The existing text is correct. It might have helped for the language to
> be a bit simpler, but it is correct.

> Reduced to its essence, the current language means:

>     The usual SMTP data-stuffing algorithm applies, so that some content
>     does not prematurely terminate the transfer of content.

> d/


> On 3/4/2019 7:30 AM, RFC Errata System wrote:
> > The following errata report has been submitted for RFC6152,
> > "SMTP Service Extension for 8-bit MIME Transport".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5646
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: HE Zhixiang <[e-mail]>
> >
> > Section: 3
> >
> > Original Text
> > -------------
> > Naturally, the usual SMTP data-stuffing algorithm applies, so that a
> > content that contains the five-character sequence of
> > <CR> <LF> <DOT> <CR> <LF>
> > or a content that begins with the three-character sequence of
> > <DOT> <CR> <LF>
> > does not prematurely terminate the transfer of the content.
> >
> > Corrected Text
> > --------------
> > Naturally, the usual SMTP data-stuffing algorithm applies, so that a
> > content that contains the five-character sequence of
> > <CR> <LF> <DOT> <CR> <LF>
> > or a content that begins with the three-character sequence of
> > <DOT> <CR> <LF>
> > would prematurely terminate the transfer of the content.
> >
> > Notes
> > -----
> > RFC 5321, section 4.5.2:
> > Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
> >
> > 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.
> >
> > --------------------------------------
> > RFC6152 (draft-ietf-yam-rfc1652bis-03)
> > --------------------------------------
> > Title               : SMTP Service Extension for 8-bit MIME Transport
> > Publication Date    : March 2011
> > Author(s)           : J. Klensin, N. Freed, M. Rose, D. Crocker, Ed.
> > Category            : INTERNET STANDARD
> > Source              : Yet Another Mail
> > Area                : Applications
> > Stream              : IETF
> > Verifying Party     : IESG
> >


> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net