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

Vitaliy T <vitaliy.tokarev@gmail.com> Tue, 18 April 2017 17:48 UTC

Return-Path: <vitaliy.tokarev@gmail.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 827DD129408 for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 10:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JS0vJQe-mA8a for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 10:48:26 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0DB1243F6 for <ima@ietf.org>; Tue, 18 Apr 2017 10:48:25 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id z109so124792wrb.1 for <ima@ietf.org>; Tue, 18 Apr 2017 10:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZlRNDHoBPROBKiVBfn87eWf5o92BJhfjUjrUf/6fEoA=; b=m71oAYn3YndOoqxvMBHs2RIeIubiTRgvGsvfwu1MGqvWfJQiAlwOgCME3rXhEkl8Vi /BwMYN0uzB2AvE8RhqxmkNf/HUvuULhOGyUQ5sDqi7yZ66UftSbd60ow1t8TkOfMsAf8 ZdGR+wqPNdYa4op8L5bCJ8NQD2+LZ8W7QMBnNkuLSRhQJCdRp/mWM6WiFiwoTkoUpW9/ B+uYjhHLgsmN27ASkrdRFBm5GstxXhchrAoGXgV5J5k1It7l4yvLqLDl/SUInIAU3QrP CKT4F4aE1UNXFi+m4w9pINjgPsvwGbtmRi/PddH+gFcpneLKhdRvArn+WfJz7jwCqvT2 WxDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZlRNDHoBPROBKiVBfn87eWf5o92BJhfjUjrUf/6fEoA=; b=ZSiVhm0Yhzp27iVKMl1VhYecLDNS7YBC83bCZL2iG8GhXPS7N+tvPDRo0rFGTD/K++ YPF8m0RneDqpnDq3qxG0C8IrG6imiiCOyth/yvxKoCMVaR4CzYsFPU2Ft+i5Efm6V4v3 AbN/uio6w5mDpb/F1cpPZmKTv42qVdG040+0lR9WNuy9j/7XCK3Upm0X54egXmkAvH+N 4iOw5rLMTq0OFaGUPjVCGycWhmBz1jwzuZi/3b5hw/OF22+zigJkFLcxvwlaWG5AIGI/ uzR2PHOHvvEb1NvMCxgCHygvx1nlG4gITTtvATaDyTxtBIJQKAPu5ewLBFyTtC7BTXfH TOfA==
X-Gm-Message-State: AN3rC/7XkgvVg6xbnKy+NemUwtPIedBJCnaV+5jF63Jdl8qYGYdQoshp regjBwUZXg63QcYU9xZ2TswtWZZkfQ==
X-Received: by 10.223.135.84 with SMTP id 20mr22341842wrz.199.1492537704323; Tue, 18 Apr 2017 10:48:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.155.207 with HTTP; Tue, 18 Apr 2017 10:47:43 -0700 (PDT)
In-Reply-To: <D581A31CD3909B93072726D7@PSB>
References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> <CABDkf7_RJLXZ_vtOWNoSgMV8YDdmW54r_JTYjaJfsdAz-moRVQ@mail.gmail.com> <D581A31CD3909B93072726D7@PSB>
From: Vitaliy T <vitaliy.tokarev@gmail.com>
Date: Tue, 18 Apr 2017 20:47:43 +0300
Message-ID: <CABDkf78aGKtBZN6ZjOKVBnoXAe+FsSeGeN4twVOQC4JJraSCgQ@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: yaojk <yaojk@cnnic.cn>, RFC Errata System <rfc-editor@rfc-editor.org>, maowei_ietf@cnnic.cn, ben <ben@nostrum.com>, alissa <alissa@cooperw.in>, aamelnikov <aamelnikov@fastmail.fm>, jyee <jyee@afilias.info>, ima <ima@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/Xb4ASW8c91oTn_YTF3ACojzo0iM>
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: Tue, 18 Apr 2017 17:48:27 -0000

On 18 April 2017 at 19:57, John C Klensin <john-ietf@jck.com>; wrote:
> 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.

It is a question which should be identified as Errata. IMHO.

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

Yes, I understand. Your time is NOT wasted, be sure. You helped me and
probably you may help others (like me).

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

You have rise another issue on the topic. Neither [RFC6530] or
[RFC6531] have a reference to [RFC20]. And a reference to it leads to
the question in this errata.

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

If [RFC6531] will have a reference to [RFC20] then the sentence from
[RFC6531] even more confusing. Let's see what we have.

1. As [RFC20] states in section "4.2", for instance, the character "+"
is considered as a graphic character.

2. In [RFC6531] has been said in section "3.3":

  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.

3. In [RFC5322] has been said in section "3.2.3"

  atext = ALPHA / DIGIT / ; Printable US-ASCII
      "!" / "#" / ; characters not including
       "$" / "%" / ; specials. Used for atoms.
       "&" / "’" /
       "*" / "+" /
       "-" / "/" /
       "=" / "?" /
       "^" / "_" /
       "‘" / "{" /
       "|" / "}" /
       "~"

4. And later in [RFC6531] has been said:

   atext =/ UTF8-non-ascii

What statement is truth? May be a correction should look like this:

  atext = ALPHA / DIGIT / UTF8-non-ascii


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

If you see that there is no mistake, then we can close the question.

Sorry, no offends, perhaps, I am wrong. Thanks for your time.

-- 
With Best Regards,
Vitaliy V. Tokarev