+1. As Ned suggests, we certainly could have written the statement more clearly, but it is correct.
john --On Monday, March 4, 2019 09:25 -0800 Ned Freed <[email protected]> wrote: > 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 <[email protected]> >> > >> > 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 _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
