From nobody Mon Apr 4 08:49:05 2022 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF43A0D53; Mon, 4 Apr 2022 08:48:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164908732586.15991.13129125694690965385@ietfa.amsl.com> Date: Mon, 04 Apr 2022 08:48:45 -0700 Archived-At: Subject: [Emailcore] Revision of core Email specifications (emailcore) WG Virtual Meeting: 2022-05-19 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 15:48:55 -0000 The Revision of core Email specifications (emailcore) WG will hold a virtual interim meeting on 2022-05-19 from 17:00 to 18:00 Europe/London (16:00 to 17:00 UTC). Agenda: Finish rfc5321bis and possibly spend time on some A/S document issues Information about remote participation: https://us06web.zoom.us/j/85914169847?pwd=dENlcEdWK0ppWVpYQmdKVUxTNENvUT09 From nobody Mon Apr 4 09:30:18 2022 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0F3A0CDB; Mon, 4 Apr 2022 09:30:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <164908981408.13807.3320816887510596499@ietfa.amsl.com> Date: Mon, 04 Apr 2022 09:30:14 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 16:30:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Internet Message Format Author : Peter W. Resnick Filename : draft-ietf-emailcore-rfc5322bis-03.txt Pages : 56 Date : 2022-04-04 Abstract: This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5322bis-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Apr 4 10:04:18 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CC73A103F for ; Mon, 4 Apr 2022 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.net 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 rowCOBH15OEQ for ; Mon, 4 Apr 2022 10:03:57 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9E13A0ED3 for ; Mon, 4 Apr 2022 10:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1649091823; bh=u7xAwV27yXg/Rs6Y4hJLQoDM5dRHQY2GnXG+lUa36ng=; h=From:To:Subject:Date:In-Reply-To:References; b=aE6m36Hqon7Ml4x3KNkM/sQ18BaL/y+es+6qXoZuUTJiEtTLSXp98PDZX8OPgF8nA NHspDC65V/PanKyRfq7W52kaenlH3v1RLD6g0Oszaw+CqlNCrJ39jaf0KfirWPXGex PnkDuKdxLdacqtFcMo+YqsqkS/3j23JJVEh2y0Dk= From: Pete Resnick To: emailcore@ietf.org Date: Mon, 04 Apr 2022 12:03:41 -0500 X-Mailer: MailMate (1.14r5882) Message-ID: In-Reply-To: <164908981408.13807.3320816887510596499@ietfa.amsl.com> References: <164908981408.13807.3320816887510596499@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 17:04:16 -0000 The significant change here is reverting from "visible" to "printable" in sections 2.2 and 2.2.1, making it clear that "printable" does not include space, and then using VCHAR throughout the rest of the document. There's one other choice, but I'm not sure it's worth it: If I were to say "graphic characters (section 4.3 of [ANSI.X3-4.1986])", that would be closest to what we're looking for (see http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That said, it's not perfect: Section 4.2 of that document says that the space character "is interpreted both as a graphic character and as a control character". If you think using "graphic" instead of "printable" is significantly better, do say. pr On 4 Apr 2022, at 11:30, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Revision of core Email specifications > WG of the IETF. > > Title : Internet Message Format > Author : Peter W. Resnick > Filename : draft-ietf-emailcore-rfc5322bis-03.txt > Pages : 56 > Date : 2022-04-04 > > Abstract: > This document specifies the Internet Message Format (IMF), a syntax > for text messages that are sent between computer users, within the > framework of "electronic mail" messages. This specification is a > revision of Request For Comments (RFC) 5322, itself a revision of > Request For Comments (RFC) 2822, all of which supersede Request For > Comments (RFC) 822, "Standard for the Format of ARPA Internet Text > Messages", updating it to reflect current practice and > incorporating > incremental changes that were specified in other RFCs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-03.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5322bis-03 > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Apr 4 12:36:31 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4BB3A173F for ; Mon, 4 Apr 2022 12:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=XPrbKpCB; dkim=pass (2048-bit key) header.d=taugh.com header.b=SjgPYSuC 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 hkC4IDf2OhRk for ; Mon, 4 Apr 2022 12:36:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E10853A1702 for ; Mon, 4 Apr 2022 12:36:08 -0700 (PDT) Received: (qmail 22823 invoked from network); 4 Apr 2022 19:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=5925.624b48a6.k2204; bh=Z/M1JMGLztU+khE1G+B9DB5BhL6/ZpamwefylvG5KFs=; b=XPrbKpCBxa0qtzK+yq0e8IMxq16ziy0+UvUf/jfX/BOVY7iSVZ6Kx6+Z8lv9vQHV0Rs8eN+miUySz6FTfx6ic157xM8+oo3jgrZ2N7ZOgVze1oIMWWrW4b6yPCyh6AT2NRDFrncRPLhJsnfdheIVJHQ/ebVPCIT8pILZuh6y11kL4L9mIOYM9WlthEZCec9pQEsvczruEXuEcxt9VjFwlkKwTM7SxicdwLzibU8Tq9rV/hixyG7Q68vcbq7NHxY4iH/R/IXoSQzRpfmomXiswPMBD3/ZA2XFvi3cu+OUe0EbcBkx+4WzX7mBSZMcJs0VxSGp+twt1ZjGTz7j8VT1nw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=5925.624b48a6.k2204; bh=Z/M1JMGLztU+khE1G+B9DB5BhL6/ZpamwefylvG5KFs=; b=SjgPYSuCCNs6Cg9hRsm5cqOY8R9IvZwV1YvAiy7VEY9KqgAVlYpLXtTDTPBq0zAEPlLy1VdP7EzLfdBnj2xGRzT1OPtpAyJSKbxrClXivXBOXDCwpinK2SgPZu8ksLz8vwCdP8y1ttAyjj/DRZtc4fPh/3jMIOUgrDqs9drrsLFnnt4rMVh1zhrsU6ztFhHw8/vYORjy27E0ZdWWKLSb8LozFcrNBECFurEsLt47/flJt88yZFS2O+GBYk4+DwvPQzwD77ZzVjgHhpi5z8/IznCujA5BmKJVwSwUIdEtQ5BzrGpojm7/ApYc2qTan4VP8GHl59c+lvjMATNIP7iiGg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2022 19:36:06 -0000 Received: by ary.qy (Postfix, from userid 501) id 94B923AC5E82; Mon, 4 Apr 2022 15:36:05 -0400 (EDT) Date: 4 Apr 2022 15:36:05 -0400 Message-Id: <20220404193605.94B923AC5E82@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: resnick@episteme.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 19:36:28 -0000 It appears that Pete Resnick said: >The significant change here is reverting from "visible" to "printable" >in sections 2.2 and 2.2.1, making it clear that "printable" does not >include space, and then using VCHAR throughout the rest of the document. > >There's one other choice, but I'm not sure it's worth it: If I were to >say "graphic characters (section 4.3 of [ANSI.X3-4.1986])", that would >be closest to what we're looking for (see >http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That said, it's >not perfect: Section 4.2 of that document says that the space character >"is interpreted both as a graphic character and as a control character". >If you think using "graphic" instead of "printable" is significantly >better, do say. I'd leave it alone. It's horrifying enough that #'&%)!@*? is a valid header field name. The other changes look fine. Not suggesting a change here but do you remember why it refers to ANSI X3.4-1986 rather than RFC 20 which is a copy of X3.4-1968? The differences between the two are insiginificant. R's, John PS: I wonder how many message parsers do the right think (i.e., nothing) with unmatched quotes in header field names. From nobody Mon Apr 4 12:43:17 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54913A1741 for ; Mon, 4 Apr 2022 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.net 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 nRFbcYygBL5z for ; Mon, 4 Apr 2022 12:43:09 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA683A173F for ; Mon, 4 Apr 2022 12:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1649101386; bh=LkXQghaYwzNaZjKeugaPVdXgsNkv9u9c56vEvIUI10E=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=D1HZXDJYAlunK/k7zgNrOiOvMXA26uidVEEt+97O6nG2aJL9oEl6gPn5h//pePAmJ XLyO+yfClbjyfXt402VdI6FHRvdi8UKNCfRce0frHO0UTqWeQnVjSSoARTv/l+ZvS4 XJ6m160wMrPcVobFi/upbIIM7sSgRSWmDlpu1+LQ= From: Pete Resnick To: John Levine Cc: emailcore@ietf.org Date: Mon, 04 Apr 2022 14:43:06 -0500 X-Mailer: MailMate (1.14r5882) Message-ID: <032E5C11-D022-4439-9C0A-7E875266F3D5@episteme.net> In-Reply-To: <20220404193605.94B923AC5E82@ary.qy> References: <20220404193605.94B923AC5E82@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 19:43:15 -0000 On 4 Apr 2022, at 14:36, John Levine wrote: > It appears that Pete Resnick said: >> The significant change here is reverting from "visible" to >> "printable" >> in sections 2.2 and 2.2.1, making it clear that "printable" does not >> include space, and then using VCHAR throughout the rest of the >> document. >> >> There's one other choice, but I'm not sure it's worth it: If I were >> to >> say "graphic characters (section 4.3 of [ANSI.X3-4.1986])", that >> would >> be closest to what we're looking for (see >> http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That said, it's >> not perfect: Section 4.2 of that document says that the space >> character >> "is interpreted both as a graphic character and as a control >> character". >> If you think using "graphic" instead of "printable" is significantly >> better, do say. > > I'd leave it alone. It's horrifying enough that #'&%)!@*? is a valid > header field name. I'm personally always in favor of "principle of least change". > The other changes look fine. Ack. > Not suggesting a change here but do you remember why it refers to > ANSI X3.4-1986 rather than RFC 20 which is a copy of X3.4-1968? The > differences between the two are insiginificant. No mention of it in the archives. I'm guessing because it was not labeled as "Standard" back then. > PS: I wonder how many message parsers do the right think (i.e., > nothing) > with unmatched quotes in header field names. Heh. A fun thing to test, I suppose. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Apr 4 14:17:18 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1203A19CE for ; Mon, 4 Apr 2022 14:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 8bQG0zy21FS6 for ; Mon, 4 Apr 2022 14:17:14 -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 3B7833A19C7 for ; Mon, 4 Apr 2022 14:17:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nbU4W-000LN1-0R for emailcore@ietf.org; Mon, 04 Apr 2022 17:17:12 -0400 Date: Mon, 04 Apr 2022 17:17:06 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <35D40FD695219FC5D9D3F9EF@PSB> 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.10 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: [Emailcore] rfc5321bis, Ticket #60, Restricted-capability clients X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 21:17:17 -0000 Hi. In the hope of getting things moving again (and noting that the number of messages posted about rfc5321bis since the day of the plenary appears to be zero), I thought I might have a go at this. I went back to my notes to try to be sure of what we were talking about when the text went into the spec. The first part of the story comes from there: the term is in 2821 and, modulo the "submission server" issue (and noting that RFC 2476, the first "message submission" spec was published before 2821), it is unclear why questions about it didn't come up until now if they are important to spend significant time on. While I believe the relevant text could, and should, be more clear, that history does make an argument that leaving text alone that has been unchanged for 21 years and never produced significant complaints until now would be unlikely to cause major harm. However, we did change it (see below) and that made it worse. For additional context, most of the discussions about that term have appeared to assume that it is used without context. That was not the case in 2821 and 5321. The text in both 2821 and 5321 comes from a paragraph that starts out talking about s and source routes. It may be worth going back and reviewing the whole paragraph (part of Section 3.3 of RFC 5321) but the specific "restricted-capability" text reads: "These restrictions make a server useless as a relay for clients that do not support full SMTP functionality. Consequently, restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site." In the process of trying to straighten out and shorten the text about source routes, I moved and rewrote that sentence and its context to read: "Historically, the was permitted to contain a source routing list of hosts and the destination mailbox; however, source routes are now deprecated (see Appendix F.2). Restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site." Conclusion #1: That change, and how I did it, made whatever problems that may or may not have existed worse. I obviously bear the responsibility for not getting it right, but some of the cause was the WG decision to try to clear all discussion of source routes out of the document and that should be treated as a lesson. Another issue is that this is one of the places where the "client", rather than "sender-SMTP", terminology does not help with clarity. Now, the requested explanation: A restricted-capability client (sender-SMTP) is one that does not support "full SMTP capability". That includes the ability to use MX records and maintain message queues and retrying as specified in the spec. I haven't tried to think through other possible restrictions but those two are obvious. Remembering that we did wrote RFCs 2476, 4409, and 6409 on the assumption that the "submission server" was a host that would send messages outward as either a fully-conforming sender-SMTP or, perhaps, to a "forwarder" relay that was itself a fully-conforming receiver-SMTP and then sender-SMTP (rereading RFC 6409, it is probably not be as clear about that as it should be but that is out of scope for the current discussion). In terms of the code used, it might receive those messages either as a slight-restricted receiver-SMTP (on port 587 or 25) or by a variety of other means, but that is not our problem today either. There are no provisions there for relaying messages around through a collection of systems. So, some example "restricted-capability" sender-SMTPs might include: * The sender-SMTP side of an RFC 6409-conforming submission server that forwarded to a relay rather than maintaining its own queues. As hinted above, 6409 does not appear to discuss the operation of the sender side of an MSA host. * An intra-enterprise host to which submission servers forward messages but that does not, itself, maintain queuing or MX processing but, instead, forwards to another, presumably intra-enterprise host that supports those functions and interfaces with the rest of Internet. It might or might not route messages to destinations within the enterprise, presumably using internal DNS arrangements or some other (outside the spec) mechanism. * A national or regional host in an area with poor or intermittent connectivity that might handle intra-area traffic normally but that routes traffic for external Internet destinations to a common host for processing and, as needed, queuing etc. FWIW, such "poor or intermittent connectivity" environments might easily include the Mars (or even the moon), where the advantages of transmitting messages to a host acting as an interplanetary gateway -- a host that would be completely unknown to an arbitrary destination host earthside (and hence would not appear in its MX list). In each of these cases, the sender-SMTP knows which host or hosts the message should be sent to because that information is somehow configured in, not because of the MX mechanism and that is at least part of what makes it, operationally, "restricted-capability". So, options (not mutually exclusive except for the first): (1) Leave the current text alone and move on. I _do not_ recommend this. (2) Leave the current text alone but come up with better terminology and/or get the relevant sentence(s) far away from any sentence that mentions source routes. Any suggestions for better terminology should include one or more proposed terms. Suggestions about moving it would be more welcome if they included a suggestion about where to. (3) Insert a significant portion of the above, possibly rewritten, to explain and illustrate what we are talking about. An abridged version would be fine too if people want to suggest what might be trimmed. (4) Revert the attempt to clean out source route-related language to the language and organization of 5321 on the assumption that, if the move created this problem, it is likely to have created others as well. I await comments, injections of wisdom, and other responses. john (3) From nobody Mon Apr 4 14:48:25 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53C23A1A61 for ; Mon, 4 Apr 2022 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=gbSGQxA5; dkim=pass (2048-bit key) header.d=taugh.com header.b=tMXPfCAL 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 Ocr3Xlartc7X for ; Mon, 4 Apr 2022 14:48:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 506283A1A81 for ; Mon, 4 Apr 2022 14:48:17 -0700 (PDT) Received: (qmail 82820 invoked from network); 4 Apr 2022 21:48:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14382.624b679f.k2204; bh=XeFvuoZis/5PeRt+dvanHzNpDEbFaMYgaHqRB9T/tfA=; b=gbSGQxA5bGTo2eHzClQ6hMYYU2+v73AKAI1HXZvo4QYSHYZImFlZj7ES4CFWUJITg6YIEe8ZcK8f6gxcI5omzd6VLnUQJst1jMzrJ+4NTBM3bU8Xa6hqjVoZgvXZLLuHmiYjwbYXkRzgm1l1exFvcJPD+I9SKNpFIlzp3empYmrJMTMI/jPTBbV1oZLvjGICFvleur5a0gyzf3uUGSzUIyhLXkQSIJa+jlMYVMQhsu6dOL2UfDb+wSLLYv/+fJs+ieZSsrgO9xyh8C7gy1XSNZIXE8/T8TssS1FsbVph5fTI7RxL1RDQ4+/bwxhos/5+mFeH6EF2v84ihLmUzMIKkw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14382.624b679f.k2204; bh=XeFvuoZis/5PeRt+dvanHzNpDEbFaMYgaHqRB9T/tfA=; b=tMXPfCALmsi1Q4t1nnEsBExmCrKw+TMXTXIk58DLa5fUZVN2JHQsh0SEKuzKPMKUuc1un0E4BobeZ51OEfmVVDfMEJhdkF3oW0ujxgbb1yAnhy2SZvI3qTKW2etShO3BYmKwRFUJhmBd8PmoSpC5FpGqlCOh0mcFkgbmiTTLbV9PXwJ5XDmtSCvO+5mjNE6DL6yP9/jINJxI0b4AeyVGwbQLFoAE3A3PYfIG6ubQiyZd9UhtCrfMn4JrHz/cvK4flKt6wBhvp3/LmetTYE0zLSW70VhG5UWDg3LL4irTm5iVB/1pPEYMm5WKiHaV5odYlgbVE/xtZiNqRuA/B1UI6g== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2022 21:48:15 -0000 Received: by ary.qy (Postfix, from userid 501) id 993553B2D5A1; Mon, 4 Apr 2022 17:48:14 -0400 (EDT) Date: 4 Apr 2022 17:48:14 -0400 Message-Id: <20220404214814.993553B2D5A1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <35D40FD695219FC5D9D3F9EF@PSB> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal <'"?!: you would be amazed what you can put in a header field Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] rfc5321bis, Ticket #60, Restricted-capability clients X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 21:48:24 -0000 I brought this up in the first place so I suppose this is largely my fault. How about just removing the restricted-capability bit, and be done with it. > "These restrictions make a server useless as a relay for > clients. Consequently, clients MUST NOT > assume that any SMTP server on the Internet can be used > as their mail processing (relaying) site." R's, John From nobody Mon Apr 4 18:06:09 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D933A1D0D for ; Mon, 4 Apr 2022 18:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 d5ScIqta9ZVN for ; Mon, 4 Apr 2022 18:06:02 -0700 (PDT) Received: from bsa2.jck.com (ns.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 9792D3A1D07 for ; Mon, 4 Apr 2022 18:06:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nbXdw-000M1W-Mp; Mon, 04 Apr 2022 21:06:00 -0400 Date: Mon, 04 Apr 2022 21:05:54 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <20220404214814.993553B2D5A1@ary.qy> References: <20220404214814.993553B2D5A1@ary.qy> 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.10 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: [Emailcore] rfc5321bis, Ticket #60, Restricted-capability clients X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 01:06:08 -0000 --On Monday, April 4, 2022 17:48 -0400 John Levine wrote: > I brought this up in the first place so I suppose this is > largely my fault. How about just removing the > restricted-capability bit, and be done with it. > >> "These restrictions make a server useless as a relay for >> clients. Consequently, clients MUST NOT >> assume that any SMTP server on the Internet can be used >> as their mail processing (relaying) site." But that is another piece of the puzzle. Absent the "restricted-capability bit", that statement becomes a very awkward way to say "don't go looking for open relays" and raises the question about whether 5321 says clearly enough that running an open relay is bad security karma. Having been burned once already by trying to rewrite that sentence and its surroundings, I'm reluctant to suggest this but it occurs to me that the right fix, if I/we could get it right, would be to take the whole sentence (starting "Consequently") out of there and replace it (there or in a more propitious place) with one that says something like: There are two ways that sender-SMTPs can determine the next-hop system to which to send the message. One is to use the DNS and MX records as describes in Section . The other involves a next-hop destination or choice of destinations that are configured into the sender-SMTP to deal with special circumstances. Probably still not quite right but you the idea. And I wouldn't think we'd need to describe the "special circumstances" (and that, if we did, that could be pushed into the A/S). Let's see what others have to say. john From nobody Mon Apr 4 21:39:18 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1493A1EDA; Mon, 4 Apr 2022 21:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 5Aw-g6tLE655; Mon, 4 Apr 2022 21:39:10 -0700 (PDT) Received: from bsa2.jck.com (ns.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 192ED3A1ED9; Mon, 4 Apr 2022 21:39:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nbayB-000MO7-2d; Tue, 05 Apr 2022 00:39:07 -0400 Date: Tue, 05 Apr 2022 00:39:02 -0400 From: John C Klensin To: Pete Resnick , emailcore@ietf.org Message-ID: In-Reply-To: References: <164908981408.13807.3320816887510596499@ietfa.amsl.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.10 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: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 04:39:16 -0000 --On Monday, April 4, 2022 12:03 -0500 Pete Resnick wrote: > The significant change here is reverting from "visible" to > "printable" in sections 2.2 and 2.2.1, making it clear that > "printable" does not include space, and then using VCHAR > throughout the rest of the document. IMO, just right. > There's one other choice, but I'm not sure it's worth it: If I > were to say "graphic characters (section 4.3 of > [ANSI.X3-4.1986])", that would be closest to what we're > looking for (see > http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That > said, it's not perfect: Section 4.2 of that document says that > the space character "is interpreted both as a graphic > character and as a control character". If you think using > "graphic" instead of "printable" is significantly better, do > say. No. I think that just gets more more tangled up in knots. If you want to be clear about what characters are allowed, either enumerate them or use VCHAR (which enumerates them). Two suggestions, one of which I've suggested earlier and that I notice John Levine picked up in a separate note (but I _am_ suggesting a change): (1) Reference RFC 20 either in addition to or instead of X3.4-1986. Your supposition about "standard" might be correct or it might have been that the reference to NIC 7104 might have been better at the time 822 was written. Dave might remember but I can't imagine it makes much difference now. Today, the main point is that, unless one has a handy library that keeps copies of old standards around in case someone might want to do a comparison (I do; I imagine that you and John L., probably do; but, in general...) copies of X3.4-1986 (and X3.4-1968) are really hard to find. (2) In any event, if you are going to reference X3.4-1986 at all, please get rid of the anchor "[ANSI.X3-4.1986]" and replace it with, e.g., "[ASCII]" (like 2822). I don't note where the "[ANSI.X3-4.1986]" notation came from, but it seems designed to confuse some people and annoy others. The other advantage of using RFC 20 is that there actually are differences (although probably not significant for the purposes of this document) between the 1968 version and the the 1986 one (which is now formally designed as "ANSI INCITS 4-1986[R2017]". Unless you find the relationships among USAS X3.4-1968 ANSI X3.4-1986 and ANSI INCITS 4-1986[R2017] and a few other forms amusing and un-confusing, that is another reason to cite RFC 20 and be done with it, with the citation anchor as [RFC20] or [ASCII] as you prefer as long as "RFC 20" is in the body of the reference. john From nobody Mon Apr 4 21:43:33 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB23A1EE2 for ; Mon, 4 Apr 2022 21:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 6KCqAeR4GgwW for ; Mon, 4 Apr 2022 21:43:27 -0700 (PDT) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on2072e.outbound.protection.outlook.com [IPv6:2a01:111:f403:700c::72e]) (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 F2EA03A1EE0 for ; Mon, 4 Apr 2022 21:43:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h0pi0enL7PQqvdwSgnfaheSdv/xEqIIDxJiNEDmYhQxKF8GhM4ZbgfnL/RLgiDU+d4wpnl9RpIa+eF9agsgz3r+zJ+1k3fnjCnIhO0wc3HCEtRGG3sQ/NzKXWn0wPS6STlMJbkWgwXf1fPMrCo/1TPebP017I5S0kEvAq3JmKQMjl5ogcrhTLybOe1Yc3+UafUI72zH+gl2oyo8Ae2HvMl5cd1eHRrX3W/5gfB3BuwX672Hw1ONljXHfLUW2kIJq6QDlCiRFC8KGvLnUzdH6xfgpkxALFMLnKSE359bNF90q4tRLqUkyl+/n4b1Zs0W0RQaMp/sY/k/12QOb8/EdAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9AdVicgpddmubvZDOZzgO3I5s5ZjSVpce9sKTjHaeec=; b=hqY3FqFO0SyPIM0nDoPX90om+CUoVBdiuuglCGlOunkqODEKpEu5Mw18CweWc5/aPgXklvV+xRmUqDslF9HycFdZXenjFXgS9AEF6wKWYZbLGOGWB9RPA5d2sUrh48t13irlX3BrJL3PmyuaklDVJHkMU4lyAhXVncDlL+PHYgiwNsHdCh951zShEAJKogQMTPrUWAShcrwS7rSsKpjoySulyck4oiW3qQKAbHaEaY+iZnYrym+JKCtdlHoHGCtQD5UXlfQ2B1ryuWW1pF8My2MkDcchEVhhF4a55Xi1ggMHoaUEXnlxTXJZgqm4zUIz6ZC3UkbPgA/eWqBmaM1XjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9AdVicgpddmubvZDOZzgO3I5s5ZjSVpce9sKTjHaeec=; b=EL1nEB0riPPh05dK0efn52YJuinZezU1bocuesJvHxCYaF6VMPdtWYsSnLLjmTkLcGVEcBzmidt5pzrrjlpYqBJmtMY9qM8pltciYl6pkNZfLwhI8Ho+NtRhtoqVafLRSHNpDRbsxUlNuUmRWaux7Fmh4dMJtwSK0x+hr5bVKIo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by OSBPR01MB3573.jpnprd01.prod.outlook.com (2603:1096:604:40::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Tue, 5 Apr 2022 04:43:22 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::e554:e4c0:16d7:b333]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::e554:e4c0:16d7:b333%7]) with mapi id 15.20.5123.031; Tue, 5 Apr 2022 04:43:22 +0000 Message-ID: Date: Tue, 5 Apr 2022 13:43:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: John C Klensin , Pete Resnick , emailcore@ietf.org References: <164908981408.13807.3320816887510596499@ietfa.amsl.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TY2PR02CA0068.apcprd02.prod.outlook.com (2603:1096:404:e2::32) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a9a94c68-1889-4d04-032e-08da16bed017 X-MS-TrafficTypeDiagnostic: OSBPR01MB3573:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UgVPb7NtROEpaI0mHUj1squIrn3NZbi2v6qtM/0E5hbsyOrktMHgabBUsDemCDDVJNKR1wcLkBpaV9En4VG6UEjMcdgYrcegX+1VZDiCLV/Z20TkwRZYizI2uAy63DnrwCNJOcjeSpMNnSylAHCsi/ejlrqCJY9rD5IXwmS1gm/psOczc67UyYL57MiIQFZIJxrBZ744AVzSwe1Yi3Oi+Os5NqCWB6PiXVZgjKrZbCCEkMeCVRgAS5VIj1DB099tQ15e7WTAoTMNJBp52H9gSWR92g56q1vW+AneZNZlY2ts1Atawe00BRI8v4l1uXqeNvPJRv32tL+JglORa6UAvhE/gEaOQkp0gRv6fAqsLUALhpjYc0W5WO5KN+QBpQowmlerAhHgrDSrKp0zk1OIs4/P9BUaoHYDCLRXCz0MJNaDA0JJTN4NhW6WDwKkJ5Entv+HR+ZYPS0EMf4yaft1Uc1BID7t0vqA5NHDUXSv36t/ZMlkwRf60ImrZw2vSfO99YaKsbdbVoURO+IHQVmwgtnNDmAM9LpQYVdymH2/jqoUZJGQF459YvcJrtWi4HFP87zCO0nvrx3svXn15SmoDQEqL9axtj3Guy90LWByTUySlPISqAcfGSsq55bWFQZF00GHcCeX4Guog44MTxY+Tcyf3jsIvsPfUgHr8qLJTEKVbfvIffbkwCcKn+wYq9mEa1B2zZl8FwU2M/pmsz7O8ivNPNRZP4zgcpVjo7H9i43Y4L+RakLv9MgnqbuJQZYSziL1JZ5zPUrAi5FA63eK4w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(136003)(396003)(346002)(366004)(376002)(39850400004)(5660300002)(38100700002)(31696002)(6506007)(966005)(6486002)(2616005)(6512007)(86362001)(508600001)(38350700002)(52116002)(36916002)(2906002)(8936002)(53546011)(66476007)(26005)(66556008)(186003)(83380400001)(316002)(786003)(110136005)(31686004)(66946007)(8676002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VklmVWkyZ0UwbHQ2K1liczhFTjJGOXIyRDJDZHhha2oxK0RuL3orVVIrNXZ3?= =?utf-8?B?N0dZQ0NKT2pzMWZBa3JUREZyZytwMDlIRnpwZlp6blZrZDZLeE5oQjFTckRI?= =?utf-8?B?MmM2bGNGdk41Y0FpQ3FyQmdjREthL3krTTdxOHlkS3c1ejQ3elNOYnZtV2tE?= =?utf-8?B?RHFpMlpMbEtwYXJ5UGNCK1JVTytvOEtzTDQ2MGlVeklqZ2x0eVlNcWFFNklC?= =?utf-8?B?S05yU3hIa0dxS0dRQjIwSVpJaStWSFpDbGxRTjJTRW1YZDdEUDJMNS81NkpJ?= =?utf-8?B?ZFExU3lTUjlSZTI2UU81WmJtNmNoOTNFVWhtOERmL0VwMmtCZFo1N1N1c3Z1?= =?utf-8?B?RUJpeTFrSnJXTFpEa0FIdnAweDZpd05Eem53RmdVUEdUcTlYZzdRTHRma0xu?= =?utf-8?B?cWd2YitnNnZkU0lsUFBUUkhVdVBRTGI3TnVvUXlZTEY5cW9JMDFNSzNhb2w4?= =?utf-8?B?bzBWNENnNzJwNVROZTRvRHcrdDVpYXQxVUlSNDB6STVReGlwMlYrQ21oTzRs?= =?utf-8?B?Z2JNdG5xamh6U1FiRmExVWw4YVFPcEVoYTFURFZERjVycUdIaXFmTVJ6bE9P?= =?utf-8?B?SmFzY05scjdCM1FyNW1VaTIzTTArTnNvWUhyY2t1cGpLbllxb09mV3g5aWpJ?= =?utf-8?B?WUxSWjlwUlhBeEEwQThsRDAyc05hWTFpUldvL0ErOU90dlJmaXZreGJ3NnUw?= =?utf-8?B?clRxWFl6UHAydFpxRHAwVUZ3YWxENWVhS3F2ZkpGVWYyQ1QwT1FFVnNBUDFY?= =?utf-8?B?WFdPTktnU090dFA2WUF6dlI0Wk9GU0FJMEJjcnR0cGtvc0xPaUNkTFU3cXJE?= =?utf-8?B?dHZEMzIwbUFPUWxHNEhxMjBoYWozRFBsYWRsQVBRS25hcjRmVDZaaHp4TFZ5?= =?utf-8?B?eTY2MlRrTmFQTGMxb3daYk5iZmdSS1BsYnFsam1vUXNtcVVZVW96b2IyQjdN?= =?utf-8?B?ZVFTbDdDbG5mQ0R0ME0vYmM0R1BKZ2RTNDcrMVlkOEFjMEp3REpIQ0pRMDJr?= =?utf-8?B?M2ozaG1WYjcraGhZUUtDN3ZkQkh0Y0F6cG9CdEpPQmlMeVg3YlFaNWtBUjUz?= =?utf-8?B?bGZ4NFVaQVc4eUd3ZlFiRUVqeCttaTNmYTh2amlHMjdpNnp2UjFLVTQycDZ4?= =?utf-8?B?UVZIRmFCV3pWTXZFOEVOaGRPWjJwNC9hK0JqRUFQam53bkdDVjhHb1EzN2FS?= =?utf-8?B?MEFlSDlvM3VPNkR3YnU0VE9YQThGUFN4VzExcjF4THZ3QUlTQ05QalhXOVRE?= =?utf-8?B?TzQ4WTRNVkVFdkZhUFd4d0NiTjJlVWc2dUpxb0dTNGJYZVFlSFlFc20rbXhB?= =?utf-8?B?M2Y2amNqaWRDWXhJVFhBcmIydkNXaC9NOFJWUjdIdjgrRzhGMTdxTHQ5dUov?= =?utf-8?B?RzlpVU41Nmd4SHlmTFVlcjZnNTdpbnNpRlJzcTF0d1ljNnFEWGNleTlXS1Qx?= =?utf-8?B?UWFMaHhsODJwYkM4bWhiQkVWc3VaVGFjckhMaE9VbWRCWUJVTlJjZ0FyNlRH?= =?utf-8?B?NTFEU1MvcVJXS1FZUXhjVElSMGhQSW1EQS9BeW56Y1JWRE9sMjJUZ01SNVRx?= =?utf-8?B?OHhvQlBZUWhVd3BmWUs4eHBHdnFYMnZWTE0vby9xajlQQjljOWczNzRZSVhP?= =?utf-8?B?TkYwQWhGdUFOMTh5Yis4c2RTNjFibE9hYk1Rb0xraHdpUnpDZ0dVMW5DK2o4?= =?utf-8?B?ZlU1dUZqMWdUekJVMTZ5VVVwYWFadmZ4L0ZpOTluMVVrYjhkSHNnaUl4dTIw?= =?utf-8?B?QzNEeU5PaVR3QnZZK1Q3OW5iQXJ1UHM0bS9rWHpBU0YxaTA2S2c3SG13Wm45?= =?utf-8?B?VkUvY0JGS1Ryc3J3WGZJeHdMcm5DeUdwUXhQSi9sOUxIb25DeGh1ektScjdx?= =?utf-8?B?S3VrbytaMlNtbzNxNWwzdDFtWXR2d2JoYWp5cEVrTmpvSkJlM3Y1Qk1ieVBM?= =?utf-8?B?L0E5WXRGakdZM3NxTGExcDBreFZwNkgzY2J5OTFOaVU0R1dUWnRtdEhvdVpR?= =?utf-8?B?NGhVWjFqVGh5YVcybkk0VXFJVHdzKy9WdVRSc1NQRE5yb0ltT0R0cTdaNUgy?= =?utf-8?B?bTh1UVJLK0RQZVRYWlRyNkY3Sk9qM25WdS9qaG1aTlhaYmhoSkdvRDdVT3hN?= =?utf-8?B?SDVEbmxkYldvTHdtZlZwS1VVWFZWZUZBQ0ZGVjh3b2ltbDFkeWhnb0xzKzVI?= =?utf-8?B?dnJIaG9YaFNwNk0zRHpwOWVUSklyNlJKcWlPVXpkbXZMeXBhalhzNjRCMndR?= =?utf-8?B?bEw5Sm9xY1hKcnZlanYwMjFVSnFyRndDVGRYZTVqcGY4aERTNTNrLys5SFcv?= =?utf-8?B?ZEdTM01lc2s0SmJtVm00VmxmY2lLbXlCd2pvU0ZRRng5WDZjL2NSdz09?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: a9a94c68-1889-4d04-032e-08da16bed017 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2022 04:43:21.9143 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hd2dmy2QnyYhGfpwHKGSAhv43+WT14Me1Rq9GyOCcjFfhceNkAi/0s5r4aadmM+OKJoDlj9E+sf0bRLLQe19aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3573 Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 04:43:32 -0000 In general, I'd prefer [US-ASCII] to just [ASCII] for the anchor. Regards, Martin. On 2022-04-05 13:39, John C Klensin wrote: > > > --On Monday, April 4, 2022 12:03 -0500 Pete Resnick > wrote: > >> The significant change here is reverting from "visible" to >> "printable" in sections 2.2 and 2.2.1, making it clear that >> "printable" does not include space, and then using VCHAR >> throughout the rest of the document. > > IMO, just right. > >> There's one other choice, but I'm not sure it's worth it: If I >> were to say "graphic characters (section 4.3 of >> [ANSI.X3-4.1986])", that would be closest to what we're >> looking for (see >> http://sliderule.mraiow.com/w/images/7/73/ASCII.pdf). That >> said, it's not perfect: Section 4.2 of that document says that >> the space character "is interpreted both as a graphic >> character and as a control character". If you think using >> "graphic" instead of "printable" is significantly better, do >> say. > > No. I think that just gets more more tangled up in knots. If > you want to be clear about what characters are allowed, either > enumerate them or use VCHAR (which enumerates them). > > Two suggestions, one of which I've suggested earlier and that I > notice John Levine picked up in a separate note (but I _am_ > suggesting a change): > > (1) Reference RFC 20 either in addition to or instead of > X3.4-1986. Your supposition about "standard" might be correct > or it might have been that the reference to NIC 7104 might have > been better at the time 822 was written. Dave might remember > but I can't imagine it makes much difference now. Today, the > main point is that, unless one has a handy library that keeps > copies of old standards around in case someone might want to do > a comparison (I do; I imagine that you and John L., probably do; > but, in general...) copies of X3.4-1986 (and X3.4-1968) are > really hard to find. > > (2) In any event, if you are going to reference X3.4-1986 at > all, please get rid of the anchor "[ANSI.X3-4.1986]" and replace > it with, e.g., "[ASCII]" (like 2822). I don't note where the > "[ANSI.X3-4.1986]" notation came from, but it seems designed to > confuse some people and annoy others. > > The other advantage of using RFC 20 is that there actually are > differences (although probably not significant for the purposes > of this document) between the 1968 version and the the 1986 one > (which is now formally designed as "ANSI INCITS 4-1986[R2017]". > Unless you find the relationships among > USAS X3.4-1968 > ANSI X3.4-1986 and > ANSI INCITS 4-1986[R2017] > and a few other forms amusing and un-confusing, that is another > reason to cite RFC 20 and be done with it, with the citation > anchor as [RFC20] or [ASCII] as you prefer as long as "RFC 20" > is in the body of the reference. > > john > From nobody Mon Apr 4 22:40:26 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A033F3A1F72; Mon, 4 Apr 2022 22:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 Pii23wU3BlZR; Mon, 4 Apr 2022 22:39:56 -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 EA3783A1F71; Mon, 4 Apr 2022 22:39:55 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nbbuy-000MSS-MG; Tue, 05 Apr 2022 01:39:52 -0400 Date: Tue, 05 Apr 2022 01:39:47 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Pete Resnick , emailcore@ietf.org Message-ID: <4DC22FF515E18AD2C93127DE@PSB> In-Reply-To: References: <164908981408.13807.3320816887510596499@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 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: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 05:40:01 -0000 --On Tuesday, April 5, 2022 13:43 +0900 "Martin J. D=C3=BCrst" wrote: > In general, I'd prefer [US-ASCII] to just [ASCII] for the > anchor. Martin, for the anchor, I really don't care as long as it isn't complicated and confusing like "[ANSI.X3-4.1986]". I prefer [ASCII] or [RFC20] to [US-ASCII], but not by much. As you have probably noticed, I completely gave up on similar debates with 2821 and 5321 and went to numeric anchors. I'm much more concerned about the term used to refer to the CCS in running text. But, out of curiosity, why do you prefer [US-ASCII]? AFAICT, it does not convey any extra information. In particular, it is not as if "ASCII" is ambiguous because there are things like JP-ASCII, CH-ASCII, GB-ASCII, or other such things floating around. There aren't. john From nobody Mon Apr 4 23:44:24 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4C3A2155 for ; Mon, 4 Apr 2022 23:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 a1iYgOASVVfy for ; Mon, 4 Apr 2022 23:44:18 -0700 (PDT) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20729.outbound.protection.outlook.com [IPv6:2a01:111:f403:7010::729]) (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 AB5093A214E for ; Mon, 4 Apr 2022 23:44:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NidyEzQEnAjaHAgXB234iGU5uNeqDMUHZt1sGPFgZ4HjIOCJM3R7yfnWZOTgVufQoOtUDjP3pwQGlxJKkewGmGclNS61p03Md3h5cVLmn116apcymVpbhjNNnc+EkGj+vlhKL+5fGmL1pbR9BJ/WO2dfYmUAad5QbvKn3wQ+YZfAxru2Gvgy5QWHwBKsXN9RbMjYdAfP/GMAjstVK4BgUJHb0AF+n7kL29u0Dqjx+xpNZR3jp11m1ec0z19Hq3xbLo+4IBSgBwmFWWyRPZRHZ3QJSZfZFKbQYjHlh4Z6xcofCW8Zj6etTuU8aup8QGlS9kF9vzKYHrWL8bm2r1nb1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yoNdfakzLkmhThmdF1STn5DBaatL5asokr59VR99N/c=; b=negjQ/A6DMHxeYd+BhjjnVkgQvSvxJWbjJVgVb04UtXKi34fQvoGW5knDMUYn6KRNYTtxgVTg/6SzBCplXa5HBvvNxETfJRo1KNhkj1PTPU9GabTOfk+IR+qgnfwegmiwW9NOOhTA6AQOM4Kmw9/YuIYAHhEdMI7EPewK/UKjun89m+FAP9puKwKdoPNgaiXhm++xWv84GFaVOXAY1T7idJsBfJK6aUKd2avhEBsdsQg0U4fLYJ1QxEJ5PR5+12y9HYciFT8m8CMQyJwONYhOdrcQfmQe3GH8odtiJGWex+PnTUcJaswh9V/lw1dOmG7pbYoeJPAUXB+SmoTUj7YcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoNdfakzLkmhThmdF1STn5DBaatL5asokr59VR99N/c=; b=A9U3IrlMPgUksq5pVi9opKtfueIn/8FUL2pcjaQ831YE8YRDuXwAaDPF+Gmn/6tAd4SNcVxcfG8oL2fHUWteA/h2VgnVYUr2V9ueYNQltHYszdbEzjpCyolFPT53p2y76cBsISEL/I5Q6JtgsjOMsWWWyzM7ahnH2u2kOUOZYfk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by OSAPR01MB2385.jpnprd01.prod.outlook.com (2603:1096:603:37::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Tue, 5 Apr 2022 06:44:14 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::e554:e4c0:16d7:b333]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::e554:e4c0:16d7:b333%7]) with mapi id 15.20.5123.031; Tue, 5 Apr 2022 06:44:13 +0000 Message-ID: Date: Tue, 5 Apr 2022 15:44:12 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: John C Klensin , Pete Resnick , emailcore@ietf.org References: <164908981408.13807.3320816887510596499@ietfa.amsl.com> <4DC22FF515E18AD2C93127DE@PSB> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <4DC22FF515E18AD2C93127DE@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0075.jpnprd01.prod.outlook.com (2603:1096:405:3::15) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 24ae5e6d-5a5b-409e-ab94-08da16cfb2ab X-MS-TrafficTypeDiagnostic: OSAPR01MB2385:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LrHXvcZw+F8BI6woMsNl/+6Wj5yznusdB2lQ4zi4jlMHZfi7C7q0Rzz4g2ms/TQwurbjK74DlK1PChUqf+xEWeYnizlfDODWJ5AqjEvePaHc/Acj8vTvNQcB732H+cBsRrce3vDMpP2N2nkotBbPmN60NJz6jRDa+u9p+Ebr5iokcfEDIYou4KCnGtRcUFXHvN1gEw8qtXj0Kv4WNhgB853q5w+jcMc52PbR2X2S4B/mxW65G18/06qIsW353XnEWQf/lSquAvFopBFbI34bJgMu6vmvsvvaUhbLJRL4dFhk72NCqH+1mh1KxlHdCIW1qFRC15OPDvh9IPHas/wc8VgU21veX5u7wmcH5/5tComqTzzNYfT1B9nMPZG1F5XLx6V53c+QU4JFL8I2LZRDKXFNeW8Yg/jEa7WQr4mnghd/Kkt3YR5IwciydYgaUUjIKF3whZvBtkMRwTJ3KaYCTU9jJ5Fd3YztoDnuzYLbUx9SS+p7p+oZNrxgnrDocb6Xd2X5UWx7JP2W5X+e0iFVo4QNuDFC3N8fDGpZayUflYOrnqgZTjaEZro8RslenQTN9QgZR9KoU12pE3x6Oyf00T/CZT7CIj9z+PGHKDnwmYvoP4BE8AJ0aFvkQkMNW+rmXpQjtbVK9x9/75fIOLgC/T8BidSoAHHbcThuiwXfEh0XsuoB+hOUzQjISGEfRHb2YCFw6pUjuQxaUQ+uawRM7ZNhTvvnqPaRChubIfDMGm4VheNAQmx+sfTdcM+m0lzVN/OLNeVH3AGu2nmLCFrwuXTpLQm3Z+aNNwZFrK9W7nNzWwTPP8UooOMS7LwDk3EzomnT+W0TSfHIceyGKh30ZL79lDQRe+MbZI2mEsjL0Bc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(396003)(39850400004)(366004)(376002)(136003)(346002)(8936002)(508600001)(36916002)(6486002)(31696002)(31686004)(2616005)(86362001)(6506007)(5660300002)(966005)(8676002)(6512007)(110136005)(26005)(186003)(786003)(38100700002)(83380400001)(38350700002)(316002)(2906002)(66556008)(66476007)(66946007)(53546011)(52116002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ckdVNTNvQzkxZ0VSWG5yNDlPWlZQSW5qNXJzM1BUaFBZd0xOcmlmcS9MM1Mw?= =?utf-8?B?ZlEwK3ExcnA0ZWZuM1k4endBNHFpNWZoZEVuNlZ4UzMyWStmMnhOWVlmcERH?= =?utf-8?B?T0JVQmttNTBvMHV1ZTF1b09rSmFwMFU1YWsvblhzVk1ubWhoeStPZG45ZkJ0?= =?utf-8?B?cVJnNXcvY1h2a1BuK1lRenlJbFZjdzRvNUtjVEVQazN3VFlORzIzUlk5REph?= =?utf-8?B?aDFqVEV2NmVSblY1eFRqOGFtaTdxaHR2MGxwdTFEdU02YjY4L1ZKTHRGVFo2?= =?utf-8?B?eFNOQURubzN0Z2JzcGpXZzkwRXVKa1R1V244bXI4SjU0aFNXZzRrdm93TWRB?= =?utf-8?B?SjdRMFlTNTUwbG1ndTdhMFBkYzhRQjJrMEkzNE5xZTJhY0N3c3lvNyszektx?= =?utf-8?B?MUZpV2lqbHU0cFJyVC9SQTF1RFdRQzdPMkRKbTM3aE1YT096TnN1Nk8rSU93?= =?utf-8?B?cmJucU9IZVl2bHZCQXMzazBQWks0R1RORFdKNGhPRFBjR1I5bTBHMlVDUXdO?= =?utf-8?B?Z1E2NzRNOUUxQkQxaWRqc1hYRXo4ZUVFcWJtRkQyeWE1Q2ZxcTMyTGh4RC95?= =?utf-8?B?aFA5eDlRZDFaYVlpSFU1Z01nd3FvQUxka1NKWnl2VHlqKzZjYVlXWUNvaGZO?= =?utf-8?B?eWhORkJ2OW56Zno5WXJEQTJaektrbFdWK1h0cUMycU92dFdEN29ndkZ4VERE?= =?utf-8?B?VXR0TExZSGJhKzJIODN0UkZKM3lJYXNsUWVSKzJIUnhrUDdJTVZLL0krbGR4?= =?utf-8?B?ZXcvd1VTdUVIVXpZaDlad3NWYlowNDV0Uld2M1hNMnlkK3Q1S0lKSHNtYklX?= =?utf-8?B?R1Y2V1J5cmowbE52eE1zeUo2OVZKU2RaRGJ1MVBaREJJaFB1UkhoRW5NUnI5?= =?utf-8?B?YjUzaHplQ3VReXJuR056NUpPdWhXV2FCMEFUTVJqMXZXY3ZJRUtLM1NkWWlm?= =?utf-8?B?cTBZWjd1aFk1bkVablZnbDdtZnpVRlRJc29jMGtuZ3o4WlQyY3lla0hadGFa?= =?utf-8?B?eEZqRzVxTFk4VXIwaWszNVlkZGgzMmxyeExPRDJzYWpjNnFNK2w2QjVUOThI?= =?utf-8?B?V3hEUFJpSTIrNFg2SU8yMXc1WkFxTTREY1lUajVhcE5zRTIzUVZ3RjMxTHRj?= =?utf-8?B?UFFJZG15bkVwRjJpbEo1akhNMkdmdURyNmw5TllVbEJJdC8xRHVFN2pNdXg4?= =?utf-8?B?QXlFTmZzTmIrb1ZWMm0rYUJEdUU1MjBVcWsyOXQyNzJhR3N3eVB1WFJTeDd5?= =?utf-8?B?TlBkWEZWeW5odzRVd2U3Qmx3bGhOR2tJd3ZxKzBwaFNQUXpqMHkwYzIwbXV6?= =?utf-8?B?WXhPSWd5RTkySjIyY3dnL1ZZLysxRVcwNkZ4SkpwV1h0dWxsZy93QjBlVEpJ?= =?utf-8?B?NldtcWxKTjNFQXpPamVlaWk1UlFxa0xuTXdyODBPdHM1R2RaM0xQaUswU0tj?= =?utf-8?B?Mjg2elNyOUJZZy9ZZFpWRXJPNkxnYzdESldzWWw1OXlhaUhoV0tYL1MvVDUy?= =?utf-8?B?NFExb1J0STB4UDVEUEUvQlNwdmRoaklvaXZZR25Ld3l4NVBuRFNvREJBYmJY?= =?utf-8?B?QW54ZUZMVWFyWFdlU2VaR292ejBSQ3JYaUZtZHdLUFlKVG5oaS91Y3BzdHlz?= =?utf-8?B?c0RtN0lxaEZ2cFM3UUNzb0MvNHpqaG1tN3A0MUJIQjFaMzVJVktJci9KMmEy?= =?utf-8?B?cWVXWFdZOTdtclBDNHEwUHNUMUZKeFBtaWtzOExtb0EvZklieGxoeHkzQVZ0?= =?utf-8?B?V1UwajF4R3IyenFPNXB3SFFMQWFxb1dmY1djdDlJVzl2M3JVcG5KQ2w1RDFm?= =?utf-8?B?Yld2a2l4NUhjL0ZYK09XWk8zWk5Rc3pIeWFYOW4vMmdUWDVFbmVyVzE4bnZN?= =?utf-8?B?Vm1yNTVWQm5VbUxrbmZnbVV5MUt0S2tHa1Q4aDlVekl6OWZVa3NxRG1BKzdO?= =?utf-8?B?VUtzQ3pBRmNFRTZTUW85V00wOFo1SXY5cEQ5VGRxYlFXeldYQWNWTE1NZXBt?= =?utf-8?B?MnlJWXpNZTN3QXV5dU9ERy9QWjhkSUtHLzQ5ZHpTVDluRjJKRTluQzBXSlNO?= =?utf-8?B?SlRJSDMzRjl3L2JFRWlTZm0wWEJTZmsvNjlhMVYyTUZRam90OCtpdGxFWXpC?= =?utf-8?B?elNObUMzS290ZlQ2VUgzZUJ1eGt6YWE3cCtOMmNiNnFvTU9nV0ZYbUl6aW5y?= =?utf-8?B?TlZTMllJL0NYN0x4VWNpN3VrWkp3NHllRW45WHVUUmVUdytqYlBmcC9zNHM2?= =?utf-8?B?eFRPTWtyeVkwNlZOcUdMbjdlSlhUTHhyMjI5OTV6SVprV0wxSzFCdHNjbVFI?= =?utf-8?B?VDdSQ0tybGw4ZGJtTjZVWFZXd2RaYUhXVFJ5THlRdFdsbU9zWnZUTGlZazM5?= =?utf-8?Q?BDcgDwS43ebgHKC8=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 24ae5e6d-5a5b-409e-ab94-08da16cfb2ab X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2022 06:44:13.8763 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: lyFO7OkkgwyZKRNgjUKXWXc9kLv4q9zty8SL4JAVRWJqJ25R7b/uqo1483/iZ84ye9aHa/k9fkVU8ZXzsN5o/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB2385 Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 06:44:24 -0000 Hello John, On 2022-04-05 14:39, John C Klensin wrote: > > > --On Tuesday, April 5, 2022 13:43 +0900 "Martin J. Dürst" > wrote: > >> In general, I'd prefer [US-ASCII] to just [ASCII] for the >> anchor. > > Martin, for the anchor, I really don't care as long as it isn't > complicated and confusing like "[ANSI.X3-4.1986]". I prefer > [ASCII] or [RFC20] to [US-ASCII], but not by much. As you have > probably noticed, I completely gave up on similar debates with > 2821 and 5321 and went to numeric anchors. > > I'm much more concerned about the term used to refer to the CCS > in running text. > > But, out of curiosity, why do you prefer [US-ASCII]? My short answer is https://www.iana.org/assignments/character-sets/character-sets.xhtml (first entry). The US-ASCII label is firmly and widely established. > AFAICT, it > does not convey any extra information. In particular, it is not > as if "ASCII" is ambiguous because there are things like > JP-ASCII, CH-ASCII, GB-ASCII, or other such things floating > around. There aren't. Yes, there are no such labels. And the ISO 646 variants for which they might have been used aren't in wide use anymore. But as far as I have heard from people with experience in this area that goes back farther than mine, these ISO 646 variants were the reason the label US-ASCII was introduced. Regards, Martin. > > john >