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

[Vitaliy T <[e-mail]>]

Hello,

On 18 April 2017 at 09:27, Jiankang Yao <[e-mail]> wrote:
> My personal feeling is that it might not be an Errata.

That's OK. I did not intended to be correct. Basically this was just a question.

> 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.
>

Sorry, but there is no clear definition what the "ASCII graphics
[characters]" is.

> 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.

So, that means there is enough the current ABNF definition:

  atext =/ UTF8-non-ascii

I suggest either to clarify what ASCII graphics characters are or just
remove that sentence. Without such a clarification the readers must
hope that they understood you right and do the next things:

1) accepts only valid UTF-8 strings (there is no a single octet
character in range %d80-FF, anything that starts from %d80 is a
multi-octet character);
2) accepts printable characters within <atext> definition as described
in [RFC5321] and [RFC5322]. E.g. accepts ASCII characters "!", "#",
"^", "{", "}", etc.;
3) do NOT add new or own rules to existing ones.

As Ned Freed said the definition of ASCII graphics is not well
defined. For instance, someone may look at

  pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

and will see that graphic characters are crossing with the definition
of <atext> [RFC5322]. Someone else may think about Extended ASCII
graphic characters (still they are not permitted in UTF-8). And others
will ignore that sentence, because [RFC5322] clearly states what ASCII
characters are permitted within <atext>.

In the end, thank you very much for your responses. In my case, I
simply ignored that sentence and used only the new ABNF rules (still
keeping hope that I do it right). I think it is possible to keep the
current text of [RFC6531] as is, but public this Errata for those who
will be confused.


-- 
With Best Regards,
Vitaliy V. Tokarev