From nobody Wed Apr 1 01:38:03 2020 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 CE1DC3A044F for ; Wed, 1 Apr 2020 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 UgOxmZZJdLE2 for ; Wed, 1 Apr 2020 01:38:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BBD3A044E for ; Wed, 1 Apr 2020 01:38:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D051F40723; Wed, 1 Apr 2020 01:37:56 -0700 (PDT) To: abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, john-ietf@jck.com, jyee@afilias.info X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: vesely@tana.it, ima@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200401083756.5D051F40723@rfc-editor.org> Date: Wed, 1 Apr 2020 01:37:56 -0700 (PDT) Archived-At: Subject: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 08:38:02 -0000 The following errata report has been submitted for RFC6532, "Internationalized Email Headers". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6036 -------------------------------------- Type: Technical Reported by: Alessandro Vesely Section: GLOBAL Original Text ------------- A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. Corrected Text -------------- In particular, Section 5.1 of RFC 2045, "Syntax of the Content-Type Header Field", deserves an extension: token /= UTF8-non-ascii similar to the extensions given to various text types given in Section 3.2. Notes ----- Various header fields are defined in terms of the grammar defined in RFC 2045. In particular, the missing extension of token was reported for Authentication-Results: https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuwD48nwptzU Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6532 (draft-ietf-eai-rfc5335bis-13) -------------------------------------- Title : Internationalized Email Headers Publication Date : February 2012 Author(s) : A. Yang, S. Steele, N. Freed Category : PROPOSED STANDARD Source : Email Address Internationalization Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Apr 1 09:35:03 2020 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 3CA043A12AB for ; Wed, 1 Apr 2020 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=U1qBsKaM; dkim=pass (1536-bit key) header.d=taugh.com header.b=MDF0ief6 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 aN5UnR3vNdNP for ; Wed, 1 Apr 2020 09:34:52 -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 81A653A129A for ; Wed, 1 Apr 2020 09:34:52 -0700 (PDT) Received: (qmail 7322 invoked from network); 1 Apr 2020 16:34:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1c98.5e84c2ab.k2004; bh=xUnG0M4uyZtOa0IsDKFuoI8S2nA/UusuKxMsYmTjHck=; b=U1qBsKaMB7fjEmVaw9F6WO+upL0Kt2RPmnnRQ1t+z93KWzB9LCKpjbZ2wBxJPWHO/JOq3QiT3OGgzsMHDXU1Jti8pzefhYQH2RkvrlqizQZfPiEBDjBDZYFJpi/wGPd4RCCmHUsVZoADoxO4kzSI2sFBIux200T/dDOfrNGXpdJJ+K6/Q4oXsafNQWsTcBB2IQxIGLfbztFnbxGG4VFTW/HTkRA42PadPvamqr2/knArNdlLjDnF1O41h8v+TJxz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1c98.5e84c2ab.k2004; bh=xUnG0M4uyZtOa0IsDKFuoI8S2nA/UusuKxMsYmTjHck=; b=MDF0ief6f8UK7pbA8DkfU8kbl9I7SEJz1KmejrYY/j+k9fHnK6Kq3bGJEfF05JF4KK1kg7ZYA4CYZWfs1+VVZNPHOrh6vJkFNUR7UWj8Uft4JG+ZL4v6Vaivk3e3spQfkJQnY9UjWenx4jH+ONzpka3tTMeOeD9O61MqKx44jhHZ7aHnNCmP4ZM9af5DrwqCutyzfvm9of4KAsRB/KIX/0vEoFphghybmLZthWXsMYcoV/IHrKsUNHhaTk1n1aY4 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 ESMTP via TCP6; 01 Apr 2020 16:34:50 -0000 Received: by ary.qy (Postfix, from userid 501) id AC54716DE75A; Wed, 1 Apr 2020 12:34:50 -0400 (EDT) Date: 1 Apr 2020 12:34:50 -0400 Message-Id: <20200401163450.AC54716DE75A@ary.qy> From: "John Levine" To: ima@ietf.org In-Reply-To: <20200401083756.5D051F40723@rfc-editor.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 16:35:00 -0000 This erratum is wrong. The MIME definition of "token" is fine. In RFC 8601 we misused "token" in the Authenticated-Results header for what really is a domain name. That's what needs to be fixed, and we're discussing what the least bad fix is. R's, John In article <20200401083756.5D051F40723@rfc-editor.org> you write: >The following errata report has been submitted for RFC6532, >"Internationalized Email Headers". > >-------------------------------------- >You may review the report below and at: >https://www.rfc-editor.org/errata/eid6036 > >-------------------------------------- >Type: Technical >Reported by: Alessandro Vesely > >Section: GLOBAL > >Original Text >------------- >A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. > > >Corrected Text >-------------- >In particular, Section 5.1 of RFC 2045, "Syntax of the Content-Type Header Field", deserves an extension: > > token /= UTF8-non-ascii > >similar to the extensions given to various text types given in Section 3.2. > >Notes >----- >Various header fields are defined in terms of the grammar defined in RFC 2045. In particular, the missing extension of >token was reported for Authentication-Results: >https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuwD48nwptzU > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC6532 (draft-ietf-eai-rfc5335bis-13) >-------------------------------------- >Title : Internationalized Email Headers >Publication Date : February 2012 >Author(s) : A. Yang, S. Steele, N. Freed >Category : PROPOSED STANDARD >Source : Email Address Internationalization >Area : Applications >Stream : IETF >Verifying Party : IESG > From nobody Wed Apr 1 10:05:22 2020 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 1F94A3A13A5 for ; Wed, 1 Apr 2020 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 3bwjbygT2v5T for ; Wed, 1 Apr 2020 10:05:17 -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 F38AD3A13A1 for ; Wed, 1 Apr 2020 10:05:16 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJgnN-00023N-Ak; Wed, 01 Apr 2020 13:04:53 -0400 Date: Wed, 01 Apr 2020 13:04:47 -0400 From: John C Klensin To: RFC Errata System , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info cc: vesely@tana.it, ima@ietf.org Message-ID: <6D9862819E9E4071B83CC6D5@PSB> In-Reply-To: <20200401083756.5D051F40723@rfc-editor.org> References: <20200401083756.5D051F40723@rfc-editor.org> 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: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 17:05:22 -0000 My vague recollection is that this was an explicit decision by the WG. Essentially, just as the WG concluded that header field names should remain restricted to ASCII, the conclusion was that Content-type fields were protocol parameters, not information for the user, and that there was no need (and potentially some cost and risks) to allow non-ASCII characters or free text more generally. One could revisit that question, but I believe that the appropriate way to do it would be to generate an Internet draft that explained the issues and tradeoffs and proposed a change -- not just to RFC 6532 but to the IANA registries related to Content-type parameter values. In any event not something that is possible as a erratum because the change would change the technical requirements for an SMTPUTF8 implementation. best, john --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System wrote: > The following errata report has been submitted for RFC6532, > "Internationalized Email Headers". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6036 > > -------------------------------------- > Type: Technical > Reported by: Alessandro Vesely > > Section: GLOBAL > > Original Text > ------------- > A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. > > > Corrected Text > -------------- > In particular, Section 5.1 of RFC 2045, "Syntax of the > Content-Type Header Field", deserves an extension: > > token /= UTF8-non-ascii > > similar to the extensions given to various text types given in > Section 3.2. > > Notes > ----- > Various header fields are defined in terms of the grammar > defined in RFC 2045. In particular, the missing extension of > token was reported for Authentication-Results: > https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuw > D48nwptzU > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, > please use "Reply All" to discuss whether it should be > verified or rejected. When a decision is reached, the > verifying party can log in to change the status and edit the > report, if necessary. > > -------------------------------------- > RFC6532 (draft-ietf-eai-rfc5335bis-13) > -------------------------------------- > Title : Internationalized Email Headers > Publication Date : February 2012 > Author(s) : A. Yang, S. Steele, N. Freed > Category : PROPOSED STANDARD > Source : Email Address Internationalization > Area : Applications > Stream : IETF > Verifying Party : IESG From nobody Wed Apr 1 10:25:00 2020 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 446D23A1433 for ; Wed, 1 Apr 2020 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 4OUx9TSFSujF for ; Wed, 1 Apr 2020 10:24:56 -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 6392A3A13FE for ; Wed, 1 Apr 2020 10:24:51 -0700 (PDT) Received: (qmail 17684 invoked from network); 1 Apr 2020 17:24:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=450d.5e84ce61.k2004; i=johnl-iecc.com@submit.iecc.com; bh=Ol0KRiGD6UasY+naYbR0rp4Qbx8jYrmKt1I0LfKQblI=; b=gxQkOr+0PL1fFbnext7FRFLQIB2nFUNzEiX+s3/I9xDOGm357hZYJubQXWg3rYzcvfduDp9QWD2cnDF7t1zWzjhjGgVX+t7Jv1lBbSdm5Wh2G+fvbokkLoo4NrEcC2pcLc9Dkq0PynHWHRakuFFyUOQKNmkmLZ2WRscBpq2UIi1IsTG57ctoceO52m1PVOP9cM3FmEHZjLtvNioE5BR04rdIFd52+H0ZUfn4m9M+wObhfwRDDz+449+bRTDq3AMz Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 Apr 2020 17:24:49 -0000 Date: 1 Apr 2020 13:24:49 -0400 Message-ID: From: "John R. Levine" To: "John C Klensin" , "RFC Errata System" , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info Cc: vesely@tana.it, ima@ietf.org In-Reply-To: <6D9862819E9E4071B83CC6D5@PSB> References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 17:24:58 -0000 I would suggest rejecting this erratum. The motivation is that "token" is imported into RFC 8601 where we have found some unfortunate results, but the solution is to fix 8601, which we're working on. R's, John On Wed, 1 Apr 2020, John C Klensin wrote: > My vague recollection is that this was an explicit decision by > the WG. Essentially, just as the WG concluded that header > field names should remain restricted to ASCII, the conclusion > was that Content-type fields were protocol parameters, not > information for the user, and that there was no need (and > potentially some cost and risks) to allow non-ASCII characters > or free text more generally. One could revisit that question, > but I believe that the appropriate way to do it would be to > generate an Internet draft that explained the issues and > tradeoffs and proposed a change -- not just to RFC 6532 but to > the IANA registries related to Content-type parameter values. > > In any event not something that is possible as a erratum because > the change would change the technical requirements for an > SMTPUTF8 implementation. > > best, > john > > > --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System > wrote: > >> The following errata report has been submitted for RFC6532, >> "Internationalized Email Headers". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6036 >> >> -------------------------------------- >> Type: Technical >> Reported by: Alessandro Vesely >> >> Section: GLOBAL >> >> Original Text >> ------------- >> A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. >> >> >> Corrected Text >> -------------- >> In particular, Section 5.1 of RFC 2045, "Syntax of the >> Content-Type Header Field", deserves an extension: >> >> token /= UTF8-non-ascii >> >> similar to the extensions given to various text types given in >> Section 3.2. >> >> Notes >> ----- >> Various header fields are defined in terms of the grammar >> defined in RFC 2045. In particular, the missing extension of >> token was reported for Authentication-Results: >> https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuw >> D48nwptzU >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, >> please use "Reply All" to discuss whether it should be >> verified or rejected. When a decision is reached, the >> verifying party can log in to change the status and edit the >> report, if necessary. >> >> -------------------------------------- >> RFC6532 (draft-ietf-eai-rfc5335bis-13) >> -------------------------------------- >> Title : Internationalized Email Headers >> Publication Date : February 2012 >> Author(s) : A. Yang, S. Steele, N. Freed >> Category : PROPOSED STANDARD >> Source : Email Address Internationalization >> Area : Applications >> Stream : IETF >> Verifying Party : IESG > > > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 1 10:37:59 2020 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 9D4CB3A1457 for ; Wed, 1 Apr 2020 10:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 onKhEY4Q7jEW for ; Wed, 1 Apr 2020 10:37:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EADFA3A1455 for ; Wed, 1 Apr 2020 10:37:53 -0700 (PDT) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 031Hb8Qo078061 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Apr 2020 12:37:09 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1585762633; bh=K9INn20jmB1vuGuHo4+u/wPgryPQ3y4ZNDrzZFdfotc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=U1SrzDaW2CsA1bsatSM8gjWsAWBA9mGZDKociujC6Ro+Tg44sAfdnfTmuMuy+wMvN G9FFFO/nctn9fIqD2ua3v70IRBPyi6P/B3EzI0aLj523rH22UJwAM/ul5aScAoTf6h W5jmmJ4wyMTpaDRtdUgMqbHtVhI/o8n/uqCZHIe0= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Ben Campbell In-Reply-To: Date: Wed, 1 Apr 2020 12:37:01 -0500 Cc: John C Klensin , RFC Errata System , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, Alexey Melnikov , Adam Roach , jyee@afilias.info, vesely@tana.it, ima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0201D82F-574A-4AF2-A581-05F5B736AD0D@nostrum.com> References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB> To: "John R. Levine" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 17:37:57 -0000 Please note that none of the ART ADs on this thread (and errata report) = are current. > On Apr 1, 2020, at 12:24 PM, John R. Levine wrote: >=20 > I would suggest rejecting this erratum. The motivation is that = "token" is imported into RFC 8601 where we have found some unfortunate = results, but the solution is to fix 8601, which we're working on. >=20 > R's, > John >=20 > On Wed, 1 Apr 2020, John C Klensin wrote: >=20 >> My vague recollection is that this was an explicit decision by >> the WG. Essentially, just as the WG concluded that header >> field names should remain restricted to ASCII, the conclusion >> was that Content-type fields were protocol parameters, not >> information for the user, and that there was no need (and >> potentially some cost and risks) to allow non-ASCII characters >> or free text more generally. One could revisit that question, >> but I believe that the appropriate way to do it would be to >> generate an Internet draft that explained the issues and >> tradeoffs and proposed a change -- not just to RFC 6532 but to >> the IANA registries related to Content-type parameter values. >>=20 >> In any event not something that is possible as a erratum because >> the change would change the technical requirements for an >> SMTPUTF8 implementation. >>=20 >> best, >> john >>=20 >>=20 >> --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System >> wrote: >>=20 >>> The following errata report has been submitted for RFC6532, >>> "Internationalized Email Headers". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6036 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Alessandro Vesely >>>=20 >>> Section: GLOBAL >>>=20 >>> Original Text >>> ------------- >>> A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> In particular, Section 5.1 of RFC 2045, "Syntax of the >>> Content-Type Header Field", deserves an extension: >>>=20 >>> token /=3D UTF8-non-ascii >>>=20 >>> similar to the extensions given to various text types given in >>> Section 3.2. >>>=20 >>> Notes >>> ----- >>> Various header fields are defined in terms of the grammar >>> defined in RFC 2045. In particular, the missing extension of >>> token was reported for Authentication-Results: >>> https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuw >>> D48nwptzU >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, >>> please use "Reply All" to discuss whether it should be >>> verified or rejected. When a decision is reached, the >>> verifying party can log in to change the status and edit the >>> report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC6532 (draft-ietf-eai-rfc5335bis-13) >>> -------------------------------------- >>> Title : Internationalized Email Headers >>> Publication Date : February 2012 >>> Author(s) : A. Yang, S. Steele, N. Freed >>> Category : PROPOSED STANDARD >>> Source : Email Address Internationalization >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>=20 >>=20 >>=20 >=20 > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = https://jl.ly From nobody Wed Apr 1 11:17:18 2020 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 79E003A15B6 for ; Wed, 1 Apr 2020 11:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 ka5LNqOPyBs7 for ; Wed, 1 Apr 2020 11:17:16 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 156CF3A15B4 for ; Wed, 1 Apr 2020 11:17:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJ6VOUSZ00003HNW@mauve.mrochek.com> for ima@ietf.org; Wed, 1 Apr 2020 11:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1585764732; bh=jZb8YVqr7I3vgxzgA1MatiEqp5fj4VEgr5mna09XWQg=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=NLN0vsOJCdPRJIvDN4oj3ZnQVK1eoe9TBTixrdfdutTNdA2trwNV2pxhJ6ERx78sQ 5Xsy9ahwJSk043vn4y32smowicz2bvWrzB1HdzJG217IyN90X4pOtCkQQRWeu2rNEP Pkad6Xezz+TN82WGxxqhwiO1NXqZ60wRdRR7chz0= 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 <01RIHLDFQH34000058@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 1 Apr 2020 11:12:09 -0700 (PDT) From: ned+ima@mrochek.com Cc: ima@ietf.org Message-id: <01RJ6VOT0NY8000058@mauve.mrochek.com> Date: Wed, 01 Apr 2020 11:11:52 -0700 (PDT) In-reply-to: "Your message dated Wed, 01 Apr 2020 12:34:50 -0400" <20200401163450.AC54716DE75A@ary.qy> References: <20200401083756.5D051F40723@rfc-editor.org> <20200401163450.AC54716DE75A@ary.qy> To: John Levine Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 18:17:18 -0000 Agreed. This should be rejected. Ned > This erratum is wrong. The MIME definition of "token" is fine. > In RFC 8601 we misused "token" in the Authenticated-Results header for > what really is a domain name. That's what needs to be fixed, and we're > discussing what the least bad fix is. > R's, > John > In article <20200401083756.5D051F40723@rfc-editor.org> you write: > >The following errata report has been submitted for RFC6532, > >"Internationalized Email Headers". > > > >-------------------------------------- > >You may review the report below and at: > >https://www.rfc-editor.org/errata/eid6036 > > > >-------------------------------------- > >Type: Technical > >Reported by: Alessandro Vesely > > > >Section: GLOBAL > > > >Original Text > >------------- > >A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. > > > > > >Corrected Text > >-------------- > >In particular, Section 5.1 of RFC 2045, "Syntax of the Content-Type Header Field", deserves an extension: > > > > token /= UTF8-non-ascii > > > >similar to the extensions given to various text types given in Section 3.2. > > > >Notes > >----- > >Various header fields are defined in terms of the grammar defined in RFC 2045. In particular, the missing extension of > >token was reported for Authentication-Results: > >https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuwD48nwptzU > > > >Instructions: > >------------- > >This erratum is currently posted as "Reported". If necessary, please > >use "Reply All" to discuss whether it should be verified or > >rejected. When a decision is reached, the verifying party > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC6532 (draft-ietf-eai-rfc5335bis-13) > >-------------------------------------- > >Title : Internationalized Email Headers > >Publication Date : February 2012 > >Author(s) : A. Yang, S. Steele, N. Freed > >Category : PROPOSED STANDARD > >Source : Email Address Internationalization > >Area : Applications > >Stream : IETF > >Verifying Party : IESG > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From nobody Wed Apr 1 11:17:29 2020 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 D6AEE3A15B4 for ; Wed, 1 Apr 2020 11:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 ADgmwUc5YWWR for ; Wed, 1 Apr 2020 11:17:16 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 547BE3A15B5 for ; Wed, 1 Apr 2020 11:17:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJ6VTI1QXC0058Z6@mauve.mrochek.com> for ima@ietf.org; Wed, 1 Apr 2020 11:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1585764960; bh=2kCcQeytb73NG9d8170cYQrKZeEYLsIoFle9YpP/T5s=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=nfQzmAiVM7DvO6NUXzS1yZAxPTSes/IKE4YuhIGctvJ7Zkm0S5u+Lq7x7ycPGvQ3e abOjgThrl61Iw83XzfmUjX1kgcvwrem67gGYpkAkeiwM+oKAnSh1SCsIAmsIW/5nRD 3flGTDRq02/MN1sqJyPdypAQdMOG9DUKJaWN7lk4= 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 <01RIHLDFQH34000058@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 1 Apr 2020 11:15:54 -0700 (PDT) From: ned+ima@mrochek.com Cc: RFC Errata System , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info, ima@ietf.org, vesely@tana.it Message-id: <01RJ6VTFO7SQ000058@mauve.mrochek.com> Date: Wed, 01 Apr 2020 11:14:49 -0700 (PDT) In-reply-to: "Your message dated Wed, 01 Apr 2020 13:04:47 -0400" <6D9862819E9E4071B83CC6D5@PSB> References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB> To: John C Klensin Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 18:17:18 -0000 Your recollection is correct and so is your point about this being a fundamental change to SMTPUTF8. There was a strong consensus that parameter names didn't need to be internationalized. Ned > My vague recollection is that this was an explicit decision by > the WG. Essentially, just as the WG concluded that header > field names should remain restricted to ASCII, the conclusion > was that Content-type fields were protocol parameters, not > information for the user, and that there was no need (and > potentially some cost and risks) to allow non-ASCII characters > or free text more generally. One could revisit that question, > but I believe that the appropriate way to do it would be to > generate an Internet draft that explained the issues and > tradeoffs and proposed a change -- not just to RFC 6532 but to > the IANA registries related to Content-type parameter values. > In any event not something that is possible as a erratum because > the change would change the technical requirements for an > SMTPUTF8 implementation. > best, > john > --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System > wrote: > > The following errata report has been submitted for RFC6532, > > "Internationalized Email Headers". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6036 > > > > -------------------------------------- > > Type: Technical > > Reported by: Alessandro Vesely > > > > Section: GLOBAL > > > > Original Text > > ------------- > > A section 3.2bis, "Syntax Extensions to RFC 2045", is missing. > > > > > > Corrected Text > > -------------- > > In particular, Section 5.1 of RFC 2045, "Syntax of the > > Content-Type Header Field", deserves an extension: > > > > token /= UTF8-non-ascii > > > > similar to the extensions given to various text types given in > > Section 3.2. > > > > Notes > > ----- > > Various header fields are defined in terms of the grammar > > defined in RFC 2045. In particular, the missing extension of > > token was reported for Authentication-Results: > > https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuw > > D48nwptzU > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, > > please use "Reply All" to discuss whether it should be > > verified or rejected. When a decision is reached, the > > verifying party can log in to change the status and edit the > > report, if necessary. > > > > -------------------------------------- > > RFC6532 (draft-ietf-eai-rfc5335bis-13) > > -------------------------------------- > > Title : Internationalized Email Headers > > Publication Date : February 2012 > > Author(s) : A. Yang, S. Steele, N. Freed > > Category : PROPOSED STANDARD > > Source : Email Address Internationalization > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From nobody Wed Apr 1 11:28:34 2020 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 218233A07AF for ; Wed, 1 Apr 2020 11:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 MqEtaO0cxD2l for ; Wed, 1 Apr 2020 11:28:30 -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 212073A07B7 for ; Wed, 1 Apr 2020 11:28:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jJi5z-0002Eb-25; Wed, 01 Apr 2020 14:28:11 -0400 Date: Wed, 01 Apr 2020 14:28:05 -0400 From: John C Klensin To: "John R. Levine" , RFC Errata System , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info cc: vesely@tana.it, ima@ietf.org Message-ID: <618B2F33973E91751E720E22@PSB> In-Reply-To: References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@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: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 18:28:32 -0000 John and I are in agreement that this should be rejected (in case it wasn't clear, I favor rejecting it too). Since neither 8601 nor its predecessors (7601, 7410, 7001, 5451, and 6577) update 6532 or the base MIME Content-type definition), I would assume that any change along these lines to 6532 would require an explicit update to (or replacement of) that document and Standards Action on that change. That is true whether the motivation for the change comes out of the Authentication Status work (and Authentication-Results header field) helped motivate the request or not and whether the definitions associated with the field are stable yet. I'm pushing back on John's justification/explanation only because this proposed change to 6532 should not come back as an erratum (updated or new) after 8601 is replaced or otherwise fixed. Let's reject it because it proposes the type of change to 6532 that is improper for an erratum. If the author of the erratum believes that the suggested change to 6532 is needed, let's see the Internet-Draft and appropriate explanation, ideally coordinated with whatever fixes are being made to 8601. I welcome any additional explanation as to why this should be rejected that relevant present or past ADs or the IESG would like to add, preferably including John's, but strongly prefer that the core reason for the rejection be about 6532 itself. best, john --On Wednesday, April 1, 2020 13:24 -0400 "John R. Levine" wrote: > I would suggest rejecting this erratum. The motivation is > that "token" is imported into RFC 8601 where we have found > some unfortunate results, but the solution is to fix 8601, > which we're working on. > > R's, > John > > On Wed, 1 Apr 2020, John C Klensin wrote: > >> My vague recollection is that this was an explicit decision by >> the WG. Essentially, just as the WG concluded that header >> field names should remain restricted to ASCII, the conclusion >> was that Content-type fields were protocol parameters, not >> information for the user, and that there was no need (and >> potentially some cost and risks) to allow non-ASCII characters >> or free text more generally. One could revisit that question, >> but I believe that the appropriate way to do it would be to >> generate an Internet draft that explained the issues and >> tradeoffs and proposed a change -- not just to RFC 6532 but to >> the IANA registries related to Content-type parameter values. >> >> In any event not something that is possible as a erratum >> because the change would change the technical requirements >> for an SMTPUTF8 implementation. >> >> best, >> john >> >> >> --On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System >> wrote: >> >>> The following errata report has been submitted for RFC6532, >>> "Internationalized Email Headers". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6036 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Alessandro Vesely >>> >>> Section: GLOBAL >>> >>> Original Text >>> ------------- >>> A section 3.2bis, "Syntax Extensions to RFC 2045", is >>> missing. >>> >>> >>> Corrected Text >>> -------------- >>> In particular, Section 5.1 of RFC 2045, "Syntax of the >>> Content-Type Header Field", deserves an extension: >>> >>> token /= UTF8-non-ascii >>> >>> similar to the extensions given to various text types given >>> in Section 3.2. >>> >>> Notes >>> ----- >>> Various header fields are defined in terms of the grammar >>> defined in RFC 2045. In particular, the missing extension of >>> token was reported for Authentication-Results: >>> https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenE >>> uw D48nwptzU >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, >>> please use "Reply All" to discuss whether it should be >>> verified or rejected. When a decision is reached, the >>> verifying party can log in to change the status and edit >>> the report, if necessary. >>> >>> -------------------------------------- >>> RFC6532 (draft-ietf-eai-rfc5335bis-13) >>> -------------------------------------- >>> Title : Internationalized Email Headers >>> Publication Date : February 2012 >>> Author(s) : A. Yang, S. Steele, N. Freed >>> Category : PROPOSED STANDARD >>> Source : Email Address Internationalization >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >> >> >> > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The > Internet for Dummies", > Please consider the environment before reading this e-mail. > https://jl.ly From nobody Thu Apr 2 01:51:40 2020 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 B1CD03A0DD5 for ; Thu, 2 Apr 2020 01:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 vKrvO0wGv8Cp for ; Thu, 2 Apr 2020 01:51:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E988E3A0DCF for ; Thu, 2 Apr 2020 01:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1585817492; bh=0tA6hjj6agcoADuGzL2EtZYkwmofa2Aa5NBB5r7dE7k=; l=1313; h=To:Cc:References:From:Date:In-Reply-To; b=AlRnSzg3PA6lOETi88yjp4VGOYC8hP9JNO5X4h1SfNXe8bvPU1Di6FySjjtjLbFWz wYATw+EJWKsZ4Cf2Cib3lfKErTybYC2fgf4rS/eMzbNDdIsZ2OqdmEOKcBT0xINr6c KnEC8ijTKdv08e9pOJ4oCFuV1w24bLRzzLwExQPl65tS+cz4qii8pIAZ1dgbE Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005E85A793.000024C4; Thu, 02 Apr 2020 10:51:31 +0200 To: Ned Freed , John C Klensin Cc: RFC Errata System , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info, ima@ietf.org References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB> <01RJ6VTFO7SQ000058@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 2 Apr 2020 10:51:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <01RJ6VTFO7SQ000058@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 08:51:38 -0000 On Wed 01/Apr/2020 20:14:49 +0200 Ned Freed wrote: > Your recollection is correct and so is your point about this being > a fundamental change to SMTPUTF8. There was a strong consensus that > parameter names didn't need to be internationalized. I didn't realize that that would change the requirements for SMTPUTF8, since actual Content-Type header fields need a registration or some kind of agreement among the parties using X-whatever tokens. RFC 5322's word term is defined quite alike, as word = atom / quoted-string. However, atom is defined in terms of atext, which is extended by RFC 6532. I hope you will excuse me for not having realized that an internationalized Content-Type: would have changed SMTPUTF8 requirements, given that non-ASCII Received: fields are already possible. Anyway, I don't know how many specs imported "value" from RFC2045. For RFC 8601, the most backward compatible fix is perhaps to import token instead of value, extend token by /= UTF8-non-ascii, and then define value using the extended token: value := token / quoted-string Oh well... if this erratum is rejected, the one needed for RFC 8601 will most likely be more complicated than this. So I think the attempt has been worth trying. Thank you everyone for your time. Best Ale -- From nobody Thu Apr 2 07:41:29 2020 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 F1AC13A13B1 for ; Thu, 2 Apr 2020 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 WGmkwD5vtEeP for ; Thu, 2 Apr 2020 07:41:11 -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 7F8943A13AE for ; Thu, 2 Apr 2020 07:41:11 -0700 (PDT) Received: (qmail 42577 invoked from network); 2 Apr 2020 14:41:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a64f.5e85f985.k2004; i=johnl-iecc.com@submit.iecc.com; bh=sl2yAWfUojq1iEEL4y0Z5D0LlNAvpbJkAhLZNE3yM58=; b=Wg9S8Q5gXaYaXq/wkOBvBajOr6T2YfuWpzKiIwcJcWF1HhgroqF2JJAbukRMGLIGaCv/i1KJ9BqKKj7pMASZ+bXRMQZ0rnku8UXDUlJKkxgJNhoaCGqsRLsGu4v9wR2PeD8lVMXEDKsF7+WSYzPMToHeKHrvHKxUyxDGxfAqcUe/mQulVoolusjJcCxJe0x9nE5kKYzTXlZepPCsdxE2bCBm2CTje/cvR5bXzXsnDBlbz9L06D9XfMqLNzcgCmFw Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Apr 2020 14:41:09 -0000 Date: 2 Apr 2020 10:41:09 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" , "Ned Freed" , "John C Klensin" Cc: "RFC Errata System" , abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jyee@afilias.info, ima@ietf.org In-Reply-To: References: <20200401083756.5D051F40723@rfc-editor.org> <6D9862819E9E4071B83CC6D5@PSB> <01RJ6VTFO7SQ000058@mauve.mrochek.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [EAI] [Technical Errata Reported] RFC6532 (6036) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:41:14 -0000 > Anyway, I don't know how many specs imported "value" from RFC2045. The ones I know immediately are a lot of MIME updates and RFC 5536 about the netnews article format. This is not a spec to change casually. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly