Re: [EAI] [Technical Errata Reported] RFC6531 (4996)
John C Klensin <john-ietf@jck.com> Tue, 18 April 2017 16:58 UTC
Return-Path: <john-ietf@jck.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 BE90F12FB9A for <ima@ietfa.amsl.com>; 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 <ima@ietfa.amsl.com>; 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 <ima@ietf.org>; 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 <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Vitaliy T <vitaliy.tokarev@gmail.com>, yaojk <yaojk@cnnic.cn>
cc: 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>
Message-ID: <D581A31CD3909B93072726D7@PSB>
In-Reply-To: <CABDkf7_RJLXZ_vtOWNoSgMV8YDdmW54r_JTYjaJfsdAz-moRVQ@mail.gmail.com>
References: <20170416203054.74AB5B8190E@rfc-editor.org> <2017041814264072046595@cnnic.cn> <CABDkf7_RJLXZ_vtOWNoSgMV8YDdmW54r_JTYjaJfsdAz-moRVQ@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/ima/9WcGGj6mZmA-BszQv1c5RNFGi2M>
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 16:58:14 -0000
--On Tuesday, April 18, 2017 18:01 +0300 Vitaliy T <vitaliy.tokarev@gmail.com> wrote: > 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. 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 <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. 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 <atext> [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 <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. 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
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… ned+ima
- [EAI] [Technical Errata Reported] RFC6531 (4996) RFC Errata System
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… Jiankang Yao
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… ned+ima
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… Vitaliy T
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… John C Klensin
- Re: [EAI] [Technical Errata Reported] RFC6531 (49… Vitaliy T