The following errata report has been su= bmitted for RFC6531,

"SMTP Extension for Internationalized Email".

--------------------------------------

You may review the report below and&nbs= p;at:

http://www.rfc-editor.org/errata_search.php?rfc=3D6531&eid=3D4996=

--------------------------------------

Type: Technical

Reported by: Vitaliy V. Tokarev <vitaliy.= tokarev@gmail.com>

Section: 3.3

Original Text

-------------

The definition of <atext> is extended&= nbsp;to permit both the RFC 5321

definition and a UTF-8 string. That str= ing MUST NOT contain any

of the ASCII graphics or control charac= ters.

Corrected Text

--------------

The definition of <atext> is extended&= nbsp;to permit both the RFC 5321

definition and a UTF-8 string. That str= ing MUST NOT contain any

of the Extended ASCII graphics (%d128-255)&n= bsp;or control characters.

Notes

-----

The question is: what is "ASCII graphic= s characters"? Either meant that is possible= to transmit 8bit characters, but they = should not be in range %d128-255. Or so= mething else. A better clarification is appr= eciated.

Instructions:

-------------

This erratum is currently posted as "Re= ported". If necessary, please

use "Reply All" to discuss whether it&n= bsp;should be verified or

rejected. When a decision is reached, t= he verifying party

can log in to change the status an= d edit the report, if necessary.

--------------------------------------

RFC6531 (draft-ietf-eai-rfc5336bis-16)

--------------------------------------

Title &nbs= p; : SMTP Extension for Interna= tionalized Email

Publication Date : February 201= 2

Author(s) = : J. Yao, W. Mao

Category &= nbsp; : PROPOSED STANDARD

Source &nb= sp; : Email Address Internationalization

Area = ; : Applications

Stream &nb= sp; : IETF

Verifying Party : IESG

------=_001_NextPart418786645162_=------ From vitaliy.tokarev@gmail.com Tue Apr 18 08:01:51 2017 Return-Path: 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 ; 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 ; 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 ; Tue, 18 Apr 2017 08:01:49 -0700 (PDT) Received: by mail-wm0-x22f.google.com 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; 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 Date: Tue, 18 Apr 2017 18:01:06 +0300 Message-ID: To: yaojk Cc: RFC Errata System , "maowei_ietf@cnnic.cn" , 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-BeenThere: ima@ietf.org 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 Hello, 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 is extended to permit > both the RFC 5321 > definition and a UTF-8 string. " > It means that 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 can allow some ASCII graphics or > control characters. > In order to emphasize that 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 syntax is clearly defined, I think that this > sentence > "The definition of 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 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 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 [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 . 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 From nobody Tue Apr 18 09:58:16 2017 Return-Path: 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 BE90F12FB9A for ; Tue, 18 Apr 2017 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BHMKIXrjNFeW for ; Tue, 18 Apr 2017 09:58:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407CF12F4EA for ; Tue, 18 Apr 2017 09:58:10 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0WRq-000ByY-L6; Tue, 18 Apr 2017 12:57:50 -0400 Date: Tue, 18 Apr 2017 12:57:43 -0400 From: John C Klensin To: Vitaliy T , yaojk cc: RFC Errata System , maowei_ietf@cnnic.cn, ben , alissa , aamelnikov , jyee , ima Message-ID: In-Reply-To: References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: 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$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:58:14 -0000 --On Tuesday, April 18, 2017 18:01 +0300 Vitaliy T wrote: > Hello, > > 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. 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. Vitaliy, 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. That said, see below. >> So we have this sentence "The definition of is >> extended to permit both the RFC 5321 >> definition and a UTF-8 string. " >> It means that 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 >> can allow some ASCII graphics or control characters. >> In order to emphasize that 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. 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. >... > 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: While I'm not a huge fan of the way 6531 was written, it was good enough, and clear enough, to achieve WG and IETF consensus. Let me suggest that you are having a slightly different problem from the one you describe. 6531 (and the other SMTPUTF8 core documents) make a number of assumptions. They all depend on 6530 for definitions and context and are quite clear about that. In addition, they are add-ons to other specs for basic email specs and, to some degree at least, for basic understanding of internationalization and character coding issues. In retrospect, 6530 should probably have been a bit more explicit about the latter, but it seemed obvious. If one reads the SMTPUTF8 documents in isolation, without that context and knowledge, they probably say a lot of confusing or incomplete things. That might not have been the right set of decisions as to where these documents stopped (although I think it probably was), but they were definitely consensus decisions, make after a good deal of discussion. > As Ned Freed said the definition of ASCII graphics is not well > defined. For instance, someone may look at 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. > pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.ht > ml > > and will see that graphic characters are crossing with the > definition of [RFC5322]. Someone else may think about > Extended ASCII graphic characters (still they are not > permitted in UTF-8). I don't understand that statement. UTF-8 is simply a coding of Unicode that includes all valid Unicode code points. See RFC 3629 or the Unicode Standard. > And others will ignore that sentence, > because [RFC5322] clearly states what ASCII characters are > permitted within . > > 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. 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. And, my disturbance at the use of the errata mechanism notwithstanding, thanks for bringing this up -- if there are parts of the specs that aren't clear to a reasonable reader, we need to know about it. best, john From nobody Tue Apr 18 10:48:28 2017 Return-Path: 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 ; 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 ; 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 ; Tue, 18 Apr 2017 10:48:25 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id z109so124792wrb.1 for ; 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: References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> From: Vitaliy T Date: Tue, 18 Apr 2017 20:47:43 +0300 Message-ID: To: John C Klensin Cc: yaojk , RFC Errata System , maowei_ietf@cnnic.cn, ben , alissa , aamelnikov , jyee , ima Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:48:27 -0000 On 18 April 2017 at 19:57, John C Klensin 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 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 =3D ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / ; characters not including "$" / "%" / ; specials. Used for atoms. "&" / "=E2=80=99" / "*" / "+" / "-" / "/" / "=3D" / "?" / "^" / "_" / "=E2=80=98" / "{" / "|" / "}" / "~" 4. And later in [RFC6531] has been said: atext =3D/ UTF8-non-ascii What statement is truth? May be a correction should look like this: atext =3D 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. --=20 With Best Regards, Vitaliy V. Tokarev From nobody Tue Apr 18 11:20:34 2017 Return-Path: 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 039371292F4 for ; Tue, 18 Apr 2017 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 9bsv7SEiL9sP for ; Tue, 18 Apr 2017 11:20:30 -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 B8D4612EB20 for ; Tue, 18 Apr 2017 11:20:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDBJCIW2KW005J37@mauve.mrochek.com> for ima@ietf.org; Tue, 18 Apr 2017 11:14:58 -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; Tue, 18 Apr 2017 11:14:47 -0700 (PDT) From: ned+ima@mrochek.com Cc: Vitaliy T , yaojk , ben , aamelnikov , alissa , ima , RFC Errata System Message-id: <01QDBJCDNVXI00005B@mauve.mrochek.com> Date: Tue, 18 Apr 2017 10:22:30 -0700 (PDT) In-reply-to: "Your message dated Tue, 18 Apr 2017 12:57:43 -0400" References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> To: John C Klensin Archived-At: 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$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:20:32 -0000 > > > 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. > 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. John, the problem is that by that definition, the sentence shifts from being confusing to flat-out incorrect. The definition of atext is RFC 5322 is: atext = ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / ; characters not including "$" / "%" / ; specials. Used for atoms. "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" But according to section 4.2 of RFC 20, everything in atext other than ALPHA and DIGIT qualifies as a "graphics character". So the assertion that when atext is composed of a "UTF8 string" it MUST NOT contain "graphics characters" directly contradicts the ABNF definition of atext. The fact is, only the specials subset of graphics characters are excluded. And FWIW, I also stand by my assertion that the term "ASCII graphics characters" is not well defined - although perhaps "no longer well defined" would be a better way to put it. There is nothing in the terminology section that points a reader to the definition in ASCII or RFC 20. And based on what I see in other documents, the common use definition has shifted away from what's in the ASCII specification to something which has more utility in the modern world. In any case, IMO there are multiple technical problems with the bullet point in question - WG consensus on the text notwithstanding. Ned