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

Vitaliy T <vitaliy.tokarev@gmail.com> Tue, 18 April 2017 15:01 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 A38F112EC0C for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 08:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 2r22_roRZb5b for <ima@ietfa.amsl.com>; Tue, 18 Apr 2017 08:01:50 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 C620F12EABC for <ima@ietf.org>; Tue, 18 Apr 2017 08:01:49 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id o81so58566356wmb.1 for <ima@ietf.org>; Tue, 18 Apr 2017 08:01:49 -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; bh=3vW/rmNgHUwi6cIdalI39Kdf1YePaId4FJsn0hs4Zds=; b=eRkK0n1GbedXrINEyh/2IbeAMmCz1q5xBTVUfQ1Iy8okdVXpDNdYREyY2HYl2L8GC2 SHqgAHbhBC0ryYt3J+dcnVaH0K1FU6VvEEfvUPq0NEx/T8arMYE2fkchurp8tCunaIdS bZGpjzimO7W8XGKfoTH2fvZzHRVSjVY81wGe1CyTIO2Bt23iOIUXYStyZ1g4wFIUZtk7 JOlfiPWuJL4Pcke2KwQjA98RmZqSeSJO+bX3VzEh72f/927Uhayv+2+vXsLtsWhw/2ut 0bDfU8Riowz6RSVeu6XxQXp4BXI8G8b7Qoylqe0rozu1sPqAIIT3c2hEDhYC+VIa7ea/ kflA==
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; bh=3vW/rmNgHUwi6cIdalI39Kdf1YePaId4FJsn0hs4Zds=; b=bealU0WrPaQdD9OAR6fVmIOS3RdC9Co/ZMFbFk6jTNWOd4vNW3+aTQbo94cpnydNtF DAjhnh9SWdF6ly1ajcPThA9uA7gVg8y0RJlKoLQsnVsjIWmyggDNocDF/5vev/Fcoq5z JXlY4+3DbbAA36TxiI604Av11TY0oRCJDsCBrgFQKGX33TNR1j152NowHquljweXYveM iki8vHREBvJU4ymyN2t3xHbwLzE+EyTqJhXMn4i9321Um9REj1hN8Q8ij9uAvH5jbRMy uXULOoEcv/RJ4u2PnqojstCitoRvV+AOaamm78LKE9B7nJNG4tWMg6Dtf7KR9/fDvGEh TCIw==
X-Gm-Message-State: AN3rC/6R+1g1ygcY39t29RyrgNxJQCUrJJC/QmlDehu4WXWcI59NCMDq YgVfKYOcukA0t7dzClYfKicN0tLjHQ==
X-Received: by 10.28.97.2 with SMTP id v2mr12769067wmb.88.1492527707185; Tue, 18 Apr 2017 08:01:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.155.207 with HTTP; Tue, 18 Apr 2017 08:01:06 -0700 (PDT)
In-Reply-To: <2017041814264072046595@cnnic.cn>
References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn>
From: Vitaliy T <vitaliy.tokarev@gmail.com>
Date: Tue, 18 Apr 2017 18:01:06 +0300
Message-ID: <CABDkf7_RJLXZ_vtOWNoSgMV8YDdmW54r_JTYjaJfsdAz-moRVQ@mail.gmail.com>
To: yaojk <yaojk@cnnic.cn>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, "maowei_ietf@cnnic.cn" <maowei_ietf@cnnic.cn>, ben <ben@nostrum.com>, alissa <alissa@cooperw.in>, aamelnikov <aamelnikov@fastmail.fm>, John C Klensin <john-ietf@jck.com>, jyee <jyee@afilias.info>, ima <ima@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/SfaVVLp95BGBnkSnuAGId-ooaHc>
X-Mailman-Approved-At: Tue, 18 Apr 2017 08:24:19 -0700
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 15:04:00 -0000

Hello,

On 18 April 2017 at 09:27, Jiankang Yao <yaojk@cnnic.cn>; 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