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

[John C Klensin <[e-mail]>]

--On Tuesday, April 18, 2017 18:01 +0300 Vitaliy T
<[e-mail]> wrote:

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

If it is a question, then use of the errata system to report it
is entirely inappropriate.  RFC Editor and IESG, please mark the
proposed erratum as "rejected" for this reason and the more
substantive ones given on this list.

Vitaliy, 

I need to apologize for sounding annoyed, but the errata process
is very heavy-duty and costs a lot of people (including me in my
former WG co-chair capacity) a lot of time, time that is largely
wasted in this case.  If you have a question, please raise it on
the mailing list, even if that question is "is this a mistake in
the spec or do I just not understand the terminology or what is
going on".   If the answer is that it is an error, the errata
process works much better because you will have already
established some signs of consensus on the issues.

That said, see below.

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

Sure there is.   It is in the ASCII Standard, cited as [ASCII]
in the document.  If that is inconvenient to find, see SeIf
nothing else, see Section 4.2 of RFC 20.

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

While I'm not a huge fan of the way 6531 was written, it was
good enough, and clear enough, to achieve WG and IETF consensus.
Let me suggest that you are having a slightly different problem
from the one you describe.  6531 (and the other SMTPUTF8 core
documents) make a number of assumptions.  They all depend on
6530 for definitions and context and are quite clear about that.
In addition, they are add-ons to other specs for basic email
specs and, to some degree at least, for basic understanding of
internationalization and character coding issues.  In
retrospect, 6530 should probably have been a bit more explicit
about the latter, but it seemed obvious.   If one reads the
SMTPUTF8 documents in isolation, without that context and
knowledge, they probably say a lot of confusing or incomplete
things.  

That might not have been the right set of decisions as to where
these documents stopped (although I think it probably was), but
they were definitely consensus decisions, make after a good deal
of discussion.

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

Ned and I disagree.   See above.   Probably 6531 (and 6530)
should have referenced RFC 20 in addition to the base ASCII
spec, but there was a lot of controversy in the community about
that at the time.

> pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.ht
> ml
> 
> 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).

I don't understand that statement.  UTF-8 is simply a coding of
Unicode that includes all valid Unicode code points.  See RFC
3629 or the Unicode Standard.

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

See above.  I think the authors (again, both of 6531 and
6530)should be happy to accept an erratum that asks for
additional clarification or references, but I'm unconvinced that
you have found an error, or even a major omission, in the text.

And, my disturbance at the use of the errata mechanism
notwithstanding, thanks for bringing this up -- if there are
parts of the specs that aren't clear to a reasonable reader, we
need to know about it.

best,
    john