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

Vitaliy T <> Tue, 18 April 2017 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A38F112EC0C for <>; Tue, 18 Apr 2017 08:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2r22_roRZb5b for <>; Tue, 18 Apr 2017 08:01:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C620F12EABC for <>; Tue, 18 Apr 2017 08:01:49 -0700 (PDT)
Received: by with SMTP id o81so58566356wmb.1 for <>; Tue, 18 Apr 2017 08:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id v2mr12769067wmb.88.1492527707185; Tue, 18 Apr 2017 08:01:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Apr 2017 08:01:06 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Vitaliy T <>
Date: Tue, 18 Apr 2017 18:01:06 +0300
Message-ID: <>
To: yaojk <>
Cc: RFC Errata System <>, "" <>, ben <>, alissa <>, aamelnikov <>, John C Klensin <>, jyee <>, ima <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
X-Mailman-Approved-At: Tue, 18 Apr 2017 08:24:19 -0700
Subject: Re: [EAI] [Technical Errata Reported] RFC6531 (4996)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Apr 2017 15:04:00 -0000


On 18 April 2017 at 09:27, Jiankang Yao <> 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

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