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

[[e-mail]]

First and foremost, the suggested change in this errata isn't quite right. As
the errata itself notes, ASCII by definition specifies characters in the range
%d0-%d127, and does not include characters in the range %d128-255, so the
suggested text doesn't work.

Second, I note that when you want to know how something is defined, the place
to look is the formal definition. And the good news is the formal definition of
the modified atext in RFC 6531 is clear and correct:

  atext   =/  UTF8-non-ascii
    ; extend the implicit definition of atext in
    ; RFC 5321, Section 4.1.2, which ultimately points to
    ; the actual definition in RFC 5322, Section 3.2.3

That said, there are multiple legitimate issue with the bullet point in
question.

The first sentence of the bullet point does not match the formal specification.
In particular, it fails to say that it's the non-ASCII subset of UTF-8 that's
being added to atext. So the current text needs to be changed from:

      The definition of <atext> is extended to permit both the RFC 5321
      definition and a UTF-8 string. 

to something like:

      The definition of <atext> is extended to permit both the RFC 5321
      character repetiore and the non-ASCII subset of UTF-8.

I think this qualifies as a legitimate technical correction.

The second sentence also has issues:

      That string MUST NOT contain any of the ASCII graphics or control
      characters.

It's not clear to me why repeating the prohibition on the parts of ASCII not
allowed in atext is necessary or even desireable, especially if the first
sentence is clarified.

But even if you accept that the prohibition is useful, there are problems.

The term "ASCII control character" is well defined as meaning the range
%d0-%d31, and that range was and is forbidden for use in atext.

The term "ASCII graphic character", OTOH, is not well defined. It's sometimes
used as a synonym for "ASCII printable character", in other cases it refers
to characters in an "extendened ASCII" that fall in the range  %d127-%d255.

So this basically a mess. My suggestion would be to change it to read
something like:

     This does not add any additional ASCII characters to the atext repetoire;
     The string MUST NOT contain ASCII control characters or RFC 5321 specials.

I believe this also qualifies as legitimate technical correction.

				Ned

> 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

> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima