Re: [EAI] [Technical Errata Reported] RFC6531 (4996)

["Jiankang Yao" <[e-mail]>]

Hello all,

   Thanks a lot for Vitaliy V. Tokarev's suggested possible Errata based on the sentence below
"The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII graphics or control characters."

My personal feeling is that it might not be an Errata.


The term "UTF-8 string " is used everywhere in EAI RFCs, for examples

1)In section 7.1 RFC6530, which said   " Permits the use of UTF-8 strings in email addresses, both local
      parts and domain names."
2)In section 3.2  RFC6531, which said  "   An SMTP server that announces the SMTPUTF8 extension MUST be prepared
   to accept a UTF-8 string [RFC3629] in any position in which RFC 5321
   specifies that a <mailbox> can appear."


So we have this sentence "The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. "
 It means that <atext> allows both RFC 5321 definition and a UTF-8 string.
Since UTF-8 string includes both non-ASCII UTF-8 and ASCII UTF-8, some readers may mis-understand that <atext> can allow some  ASCII graphics or control characters. 
In order to emphasize that  <atext> does not allow any
of the ASCII graphics or control characters, we add this sentence "That string MUST NOT contain any
      of the ASCII graphics or control characters."

Because  "UTF-8 string " is used everywhere in EAI RFCs, in order to avoid the possible misunderstanding,  I remembered that the WG  suggested to add this sentence " That string MUST NOT contain any
of the ASCII graphics or control characters." when discussing this issue.


Since the formal <atext> syntax is clearly defined, I think that this sentence
"The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII graphics or control characters." will not cause any problems, and it will help the readers to understand the formal <atext> syntax and avoid the possible misunderstanding.



I hope that this clarification is clear.



Thanks a lot.



Jiankang Yao

From: RFC Errata System
Date: 2017-04-17 04:30
To: yaojk; maowei_ietf; ben; alissa; aamelnikov; john-ietf; jyee
CC: vitaliy.tokarev; ima; rfc-editor
Subject: [Technical Errata Reported] RFC6531 (4996)
The following errata report has been submitted for RFC6531,
"SMTP Extension for Internationalized Email".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6531&eid=4996

--------------------------------------
Type: Technical
Reported by: Vitaliy V. Tokarev <[e-mail]>

Section: 3.3

Original Text
-------------
The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII graphics or control characters.

Corrected Text
--------------
The definition of <atext> is extended to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any
of the Extended ASCII graphics (%d128-255) or control characters.

Notes
-----
The question is: what is "ASCII graphics characters"? Either meant that is possible to transmit 8bit characters, but they should not be in range %d128-255. Or something else. A better clarification is appreciated.

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. 

--------------------------------------
RFC6531 (draft-ietf-eai-rfc5336bis-16)
--------------------------------------
Title               : SMTP Extension for Internationalized Email
Publication Date    : February 2012
Author(s)           : J. Yao, W. Mao
Category            : PROPOSED STANDARD
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG