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

ned+ima@mrochek.com Mon, 17 April 2017 00:55 UTC

Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B02B12941C for <ima@ietfa.amsl.com>; Sun, 16 Apr 2017 17:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmaI6G_-V4ht for <ima@ietfa.amsl.com>; Sun, 16 Apr 2017 17:55:44 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5AC127444 for <ima@ietf.org>; Sun, 16 Apr 2017 17:55:43 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD94LIEBOG00481Y@mauve.mrochek.com> for ima@ietf.org; Sun, 16 Apr 2017 17:50:40 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 16 Apr 2017 17:50:37 -0700 (PDT)
From: ned+ima@mrochek.com
Cc: yaojk@cnnic.cn, maowei_ietf@cnnic.cn, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, john-ietf@jck.com, jyee@afilias.info, ima@ietf.org, vitaliy.tokarev@gmail.com, rfc-editor@rfc-editor.org
Message-id: <01QD94LH03CG00005B@mauve.mrochek.com>
Date: Sun, 16 Apr 2017 17:07:45 -0700 (PDT)
In-reply-to: "Your message dated Sun, 16 Apr 2017 13:30:54 -0700 (PDT)" <20170416203054.74AB5B8190E@rfc-editor.org>
References: <20170416203054.74AB5B8190E@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/G0SWdri-F9-nYYZ1EKpHQRKiE40>
Subject: Re: [EAI] [Technical Errata Reported] RFC6531 (4996)
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Apr 2017 00:55:45 -0000

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 <vitaliy.tokarev@gmail.com>;

> 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
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima