From nobody Tue May 4 13:41:50 2021 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 521563A12A0 for ; Tue, 4 May 2021 13:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lW0zsl0-y_DP for ; Tue, 4 May 2021 13:41:43 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7F13A129C for ; Tue, 4 May 2021 13:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 46696E451B5E; Tue, 4 May 2021 15:41:41 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlbGWNOiseun; Tue, 4 May 2021 15:41:40 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 04F5FE451B55; Tue, 4 May 2021 15:41:39 -0500 (CDT) From: Pete Resnick To: emailcore@ietf.org Cc: Dave Crocker , Keith Moore , Alessandro Vesely Date: Tue, 04 May 2021 11:45:03 -0500 X-Mailer: MailMate (1.14r5800) Message-ID: <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> In-Reply-To: <01RYDDYSYKQ60085YQ@mauve.mrochek.com> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C3E1B2BC-30B0-4AFF-8385-21D89BDCA40A_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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, 04 May 2021 20:41:48 -0000 --=_MailMate_C3E1B2BC-30B0-4AFF-8385-21D89BDCA40A_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Just trying to close the loop on this: Dave, Keith, Alessandro: Since you were the three who voiced concerns. Is the below from Ned and John acceptable? pr On 27 Apr 2021, at 18:00, Ned Freed wrote: >> --On Tuesday, April 27, 2021 17:51 -0500 Pete Resnick >> wrote: > >>> Answering a couple of items in this reply: >>> >>> On 26 Apr 2021, at 19:47, Keith Moore wrote: >>> >>>> Regarding the use of the word "obsolete" to describe once >>>> common syntax >>>> that is less favored today: Consider "legacy" as an >>>> alternative, and try >>>> to make it clear that readers need to continue to support >>>> that syntax indefnintely.   I agree that "obsolete" conveys >>>> the wrong impression. >>> >>> I grant the point that "legacy" (or, as I mentioned before, >>> "accept-only", or probably other choices) would have probably >>> been better than "obsolete". But I still haven't seen an >>> answer to: Is there a proposal to change the terminology >>> and/or the ABNF element names? Or is there a proposal to >>> better explain in section 1.2.3 (as quoted by Alessandro >>> below) that we chose a misleading or confusing name for these >>> things, and we apologize for that, but we're sticking with it >>> to avoid even more confusion? Or is there some other proposal >>> for what you all want done in the document? This editor needs >>> guidance to come up with some proposed text. > >> I'm nervous about changes either introducing errors or being >> interpreted as more than than are. Consequently my personal >> preference is that we add an explanation to section 1.2.3 along >> the lines you describe, probably add a cross-reference to that >> explanation early in Section 4, and then move on. > > +1 > > I'll again repeat that we've managed something fairly remarkable here: > A message > written in 1980 is almost certain to work with current agents. Do we > really want > to compromise this? > > Try reading an X.400-1984 message with an 1988-only version sometime. > > Ned -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_C3E1B2BC-30B0-4AFF-8385-21D89BDCA40A_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just trying to close the loop on this:

Dave, Keith, Alessandro: Since you were the three who voi= ced concerns. Is the below from Ned and John acceptable?

pr

On 27 Apr 2021, at 18:00, Ned Freed wrote:

--On Tuesday, April 27, 2021 17:51 -0500 Pete Resnick
= resnick@epis= teme.net wrote:

Answering a couple of items in this reply:

On 26 Apr 2021, at 19:47, Keith Moore wrote:

Regarding the use of the word "obsolete" to describe once=
common syntax
that is less favored today: Consider "legacy" as an
alternative, and try
to make it clear that readers need to continue to support
that syntax indefnintely.=C2=A0=C2=A0 I agree that "obsolete" conveys
= the wrong impression.

I grant the point that "legacy" (or, as I mentioned befor= e,
"accept-only", or probably other choices) would have probably
been better than "obsolete". But I still haven't seen an
answer to: Is there a proposal to change the terminology
and/or the ABNF element names? Or is there a proposal to
better explain in section 1.2.3 (as quoted by Alessandro
below) that we chose a misleading or confusing name for these
things, and we apologize for that, but we're sticking with it
to avoid even more confusion? Or is there some other proposal
for what you all want done in the document? This editor needs
guidance to come up with some proposed text.

I'm nervous about changes either introducing errors or be= ing
interpreted as more than than are. Consequently my personal
preference is that we add an explanation to section 1.2.3 along
the lines you describe, probably add a cross-reference to that
explanation early in Section 4, and then move on.

+1

I'll again repeat that we've managed something fairly rem= arkable here: A message
written in 1980 is almost certain to work with current agents. Do we real= ly want
to compromise this?

Try reading an X.400-1984 message with an 1988-only versi= on sometime.

  		Ned

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_C3E1B2BC-30B0-4AFF-8385-21D89BDCA40A_=-- From nobody Tue May 4 14:29:58 2021 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 B41EB3A14F8 for ; Tue, 4 May 2021 14:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 UOPIBSyIHkX4 for ; Tue, 4 May 2021 14:29:52 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F983A14F7 for ; Tue, 4 May 2021 14:29:51 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4C74C15CD; Tue, 4 May 2021 17:29:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 04 May 2021 17:29:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=P3kvIzNUmITBbJC/1gNLpPhRnkmCAxyklSHPekmol /U=; b=f6YIIXN8hhshbhOh3YZYMsVsyw15lkEIeIAmqkhquQPa7mE21bIHgFhqY kDRZh0XNbvso3wJipngoDdxCqJ5tw4G2tpltV352MKBRLxLZjErstjja+G9zX4Pq q79Gs5SYOur1S6B8p+IPc3G67BMJeOsLzwF1EFh/9yMkaVUuaRQAhT1iUv/RrNKA 7K5g7ijuTKxL+evQctwQBVD8Vyj1AMu+6WjOvTG4oJCepcNnTXtZry6VkKCd9dLr ujnGuBTUqzHRSHvjO0/kChQuMgvtBDT53LLtNzkEpLT+WyDisZEulw9qd3WrkBQE Y6NdwQnyArC0PaSN/xUSVr0hgoyDw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefiedgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghi thhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtoh hmqeenucggtffrrghtthgvrhhnpeehhfeutdehfefgfefghfekhefguefgieduueegjeek feelleeuieffteefueduueenucfkphepjeefrdduudefrdduieelrdeiudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 May 2021 17:29:46 -0400 (EDT) To: Pete Resnick , emailcore@ietf.org Cc: Dave Crocker , Alessandro Vesely References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> From: Keith Moore Message-ID: <7818e611-64a9-c609-cd54-77917730eb76@network-heretics.com> Date: Tue, 4 May 2021 17:29:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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, 04 May 2021 21:29:57 -0000 On 5/4/21 12:45 PM, Pete Resnick wrote: > Just trying to close the loop on this: > > Dave, Keith, Alessandro: Since you were the three who voiced concerns. > Is the below from Ned and John acceptable? > I probably have a slight preference for changing the names of ABNF productions. However "legacy" was just a suggestion and one made without a lot of thought about how much if anything should be changed.   I can certainly live with Ned & John's suggestion instead. Keith From nobody Tue May 4 14:37:01 2021 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 AE23E3A154D for ; Tue, 4 May 2021 14:36:59 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (2048-bit key) header.d=dcrocker.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 dDLFaDNoyJJl for ; Tue, 4 May 2021 14:36:54 -0700 (PDT) Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (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 8C7293A1548 for ; Tue, 4 May 2021 14:36:54 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 825219220D5; Tue, 4 May 2021 21:36:52 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-17-237.trex.outbound.svc.cluster.local [100.96.17.237]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1E97892288E; Tue, 4 May 2021 21:36:50 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.17.237 (trex/6.2.1); Tue, 04 May 2021 21:36:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Interest-Language: 397ba33431651dbe_1620164212244_1618989129 X-MC-Loop-Signature: 1620164212244:3623050071 X-MC-Ingress-Time: 1620164212244 Received: from [192.168.0.111] (c-24-130-56-204.hsd1.ca.comcast.net [24.130.56.204]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 87836204F9CE; Tue, 4 May 2021 21:36:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1620164209; bh=1lEKbDirbPXVSZt58k2gpk8hpD8oNc4ROHejS5ydJnM=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=h6LLxx2uW0HOUeRBd87ZSS7TcIDz4Ed2VGW+2W9k0mHvWasoK9Ov3YKwpWoduR6KD ImmwkGBqcIYg1yvv76unb7IMQGOfDMuEqY1sAurxVEgjY5Ibqdvtz+KC6gmcFp3kAj mCXZYIDcaLflq/OG/Sa5UyfNwmKykoSggqAaijSCu/wh3ULHLrl68sdBJFGisbZAnp e3HksrVMkYJaOuoCa45u+kgk0GsDnTZ6EETONm13CyYCGDr3kkkBYMQQthSCV1pP78 GKbhDosYt3srqbF8NmYYtnwu9PbOJbkF9GfjBFp32E8pyYgkLzJ0yHETs0v6pihONF 9i/I8UQZysnlQ== Reply-To: dcrocker@bbiw.net To: Pete Resnick , emailcore@ietf.org Cc: Keith Moore , Alessandro Vesely References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> Date: Tue, 4 May 2021 14:36:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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, 04 May 2021 21:37:00 -0000 On 5/4/2021 9:45 AM, Pete Resnick wrote: > Dave, Keith, Alessandro: Since you were the three who voiced concerns. > Is the below from Ned and John acceptable? My original posting was to raise a concern. Poor documentation language encourages poor documentation understanding. I was seeking discussion of the concern. Some of the reactions seem to have mistaken that for a demand that there be massive documentation, syntax or semantic changes, or to have found fault that the expression of concern did not also including specific recommendations. I wanted to get some agreement about the nature of the issue, before making more specific suggestions. 1. The word 'obsolete' has very clear and specific semantics. The multi-decade reality of this specification makes obvious that the term wasn't and isn't appropriate. Whether a distinction between generation and interpretation syntaxes was or remains appropriate is quite a separate matter. But the terminology is, as I noted, misleading (at best.) Happily(?) The last paragraph of Section 3.1 provides clear and precise normative guidance about the actual /use/ of the unfortunately-prefaced ABNF. This permits arguing for a minimal revision with an annotation, given the modest goals of the current effort. So, a highlighted noted that comments on the nature of the terminology choice is not unreasonable. For example, after that paragraph: NOTE: These rules have been classed as obsolete by virtue of their no longer being valid to use for message generation. Originally, it was thought that it might also be eventually possible to drop the rules from the specification, but support for old messages have remains a concern. 2. Ale's note suggesting text attempts to distinguish interpreting archived messages versus incoming ones. This draws am operationally bright line that has not been evident and might not be intended: Email parsing for incoming mail is not required to support the OBS-* rules. That's the operational effect of his language. Is that really what folk find acceptable? (Ironically, that interpretation and effect really does make the OBS-* labeling choice appropriate...) If that's really what folk want, I'll offer some tweaks to his proposed text: NEW: Section 4 of this document specifies syntax rules that are labeled "obsolete". Section 3 includes reference to these obsolete syntactic elements. They have appeared in earlier versions of this specification or have previously been widely used in Internet messages. However, these syntactic elements MUST NOT be used when generating messages conforming to the current specification and MAY NOT be used when interpreting received messages. Syntactic rules beginning with "obs-" have been determined to be non- interoperable or to cause significant problems for recipients of messages. However, old mail archives exist and are being being actively preserved. Therefore, parsers that are applied to archives that might contain older messages SHOULD support the obs- elements. There are two landmines here. One has been longstanding: The spec required supporting the obs- rules by interpreters, while also saying that the rules are obs- because they cause problems for interpreters. (The fact that the nature of the problems wasn't explained is secondary.)' This pill will cause problems but you must swallow it... The other landmine is incoming mail that contains an embedded messages from an archive. This, of course, suggests that the distinction between incoming and archive is a convenient -- but problematic -- myth, since there is no obvious labeling of mail to distinguish what version of the specification it conforms to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 4 15:20:33 2021 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 6FECA3A1796 for ; Tue, 4 May 2021 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 PWG-is5Tl5Yj for ; Tue, 4 May 2021 15:20:25 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33873A178E for ; Tue, 4 May 2021 15:20:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 87FF11528 for ; Tue, 4 May 2021 18:20:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 04 May 2021 18:20:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=8kE1DOmq+fNAsrGtmbLdLFaM939O4GoKvMSJoNmCU Wc=; b=kdRVSjda4olN0YrMsQfzQiSo82u6Tva1if1wrCQHdtl2cbaubGuLKXDc0 begYJMuetYbiY9JvCRuLKxNDuTD1apg18Mev8bgXt2yD23hi+l/A2FTj6/u//g0h qPuXeyuO2Rxst9qAvLozZuJoW52l7oXCJ4CqbxMdXauBrKymTB/6kSWr5n52p+Ly IzrjIf1V8kqkEptlQJfe9WpyMaLUKCNI91SJu/U2PIJcmXwoMtlklqswGnax4tAd 0kfB0CBgpwlVT+P73XUBUgnF3+79o3LJR0rqs8V3JV6j4gG4aDLKgJQnliJHTBIm FQD3KtkOJjyyNQ9vvMBaMsKZ8bYNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepjeefrddu udefrdduieelrdeiudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 May 2021 18:20:22 -0400 (EDT) To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> From: Keith Moore Message-ID: <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> Date: Tue, 4 May 2021 18:20:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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, 04 May 2021 22:20:31 -0000 On 5/4/21 5:36 PM, Dave Crocker wrote: > 2. Ale's note suggesting text attempts to distinguish interpreting > archived messages versus incoming ones.  This draws am operationally > bright line that has not been evident and might not be intended: > >      Email parsing for incoming mail is not required to support the >      OBS-* rules. > > That's the operational effect of his language.  Is that really what > folk find acceptable? I do not find it acceptable.   Quite the opposite, actually.  In general conforming MUAs and most other mail handling programs need be able to parse and deal with email messages containing obs- constructs. It might be tempting to try to carve out specific exceptions, such as saying that MUAs or MSAs are free to reject new messages that contain obs- constructs at the time of origination.   But mostly I think it's a Bad Idea to try to accommodate these exceptions, because there are exceptions to the exceptions.  (like resending an old message, or forwarding an old message inside a new message).   I strongly suspect that we're better off if there's a single grammar for parsing all email messages, regardless of presumed age, than to try to enumerate the specific cases in which an obs- construct should never appear.   Simpler rules make for fewer bugs, and the existing rules are complicated enough already.   (Getting rid of obs- constructs doesn't make the rules simpler, it makes them more complicated.) > There are two landmines here. > > One has been longstanding:  The spec required supporting the obs- > rules by interpreters, while also saying that the rules are obs- > because they cause problems for interpreters.  (The fact that the > nature of the problems wasn't explained is secondary.)' IMO trying to save interpreters the burden of parsing obs- constructs was always shortsighted, and should now be abandoned as a goal.    I agree with others that being able to handle 40+ year old messages with standard tools is a huge win, one which will only become more useful over time. If we still think that obs- constructs are sometimes not implemented correctly, the thing to do at this point is to develop, identify, and/or promote open source implementations that do implement them correctly, or at least without major failures. > > This, of course, suggests that the distinction between incoming and > archive is a convenient -- but problematic -- myth, since there is no > obvious labeling of mail to distinguish what version of the > specification it conforms to. IMO it's not even a convenient myth, since believing in the myth causes more problems than it solves. Keith From nobody Wed May 5 05:35:44 2021 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 E79D13A163A for ; Wed, 5 May 2021 05:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 TKSMB9iDdDsY for ; Wed, 5 May 2021 05:35:38 -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 0F38C3A1635 for ; Wed, 5 May 2021 05:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1620218132; bh=V/0ONkWLIg7OuriNkwc5zv4LLa9SPRbRrA32Kwxsc08=; l=2794; h=To:References:From:Date:In-Reply-To; b=DIo4tGZ1EvlwSki1A3CKmqnAoa+qfb1S0foppgH5GZGV3mnYtQ3sXO3pz8KwND9kG Qv5ulOOW5TyIrDGY9ncdMvIFahxu9eUXcegXpMhqq3iX9rkkrzaGNEgp3aMBVGGsJz Be6GOaL5s1heyFsXYU6amP3O5bXzw9biVYvCGTY4rywrZSPS2fNtzR9DTe/vH Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC008.0000000060929114.00006510; Wed, 05 May 2021 14:35:32 +0200 To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> From: Alessandro Vesely Message-ID: <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> Date: Wed, 5 May 2021 14:35:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 12:35:43 -0000 On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: > On 5/4/21 5:36 PM, Dave Crocker wrote: > >> 2. Ale's note suggesting text attempts to distinguish interpreting archived >> messages versus incoming ones.  This draws am operationally bright line that >> has not been evident and might not be intended: >> >>      Email parsing for incoming mail is not required to support the >>      OBS-* rules. >> >> That's the operational effect of his language.  Is that really what folk find >> acceptable? > > I do not find it acceptable.   Quite the opposite, actually.  In general > conforming MUAs and most other mail handling programs need be able to parse and > deal with email messages containing obs- constructs. There are very many programs which happen to do email, and email addresses in particular, without having to fully understand message format. > It might be tempting to try to carve out specific exceptions, such as saying > that MUAs or MSAs are free to reject new messages that contain obs- constructs > at the time of origination.   But mostly I think it's a Bad Idea to try to > accommodate these exceptions, because there are exceptions to the exceptions. > (like resending an old message, or forwarding an old message inside a new > message). Resending an old message should imply either wrapping it inside a message/rfc822 attachment or reformatting it. MUAs do reformat messages as users edit them. Mediators reformat some header fields anyway, like MIME-Version, Content-Transfer-Encoding. I think if you need to resend a message, old or new, making sure that all of its format is left intact, you're better off sealing it inside a zip. > I strongly suspect that we're better off if there's a single grammar for > parsing all email messages, regardless of presumed age, than to try to > enumerate the specific cases in which an obs- construct should never > appear. We already have syntax compartments. For example, SMTP says: for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive. Hosts that expect to receive messages is an operational category akin to the one of messages that expect to be sent. >> This, of course, suggests that the distinction between incoming and archive >> is a convenient -- but problematic -- myth, since there is no obvious >> labeling of mail to distinguish what version of the specification it conforms >> to. > > IMO it's not even a convenient myth, since believing in the myth causes more > problems than it solves. Obsolete messages don't have to be a myth. Yet they exist. Best Ale -- From nobody Wed May 5 08:54:14 2021 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 EAF6E3A1511 for ; Wed, 5 May 2021 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_FILL_THIS_FORM_SHORT=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=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 jQk4y4IFxOTq for ; Wed, 5 May 2021 08:54:07 -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 6F4373A14FF for ; Wed, 5 May 2021 08:54:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYO4Z6LAWG00HECJ@mauve.mrochek.com> for emailcore@ietf.org; Wed, 5 May 2021 08:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620229743; bh=2JwOt5KfQ5L2EH8TF861m6avMxTRJi0eR44ica+JttU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=TOZIEQ0q18EWaDclHyunEwgPdoY38nvO0x13Cz0Pe/OS/8y7waQ5A9Vys5lJ2nqjQ NseKscEsrH4awl4X/qCABqFu/ETp1J/dmWQdhzsCACEqIKhfuBSDw2PZ0kt3aEW0Ik 6/OhhD17Mcjfi2ObNPZCkq+nRLkNNv8AI2crr/qw= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Wed, 5 May 2021 08:49:01 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> Date: Wed, 05 May 2021 08:05:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 May 2021 14:35:31 +0200" <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 15:54:12 -0000 > On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: > > On 5/4/21 5:36 PM, Dave Crocker wrote: > > > >> 2. Ale's note suggesting text attempts to distinguish interpreting archived > >> messages versus incoming ones.  This draws am operationally bright line that > >> has not been evident and might not be intended: > >> > >>      Email parsing for incoming mail is not required to support the > >>      OBS-* rules. > >> > >> That's the operational effect of his language.  Is that really what folk find > >> acceptable? > > > > I do not find it acceptable.   Quite the opposite, actually.  In general > > conforming MUAs and most other mail handling programs need be able to parse and > > deal with email messages containing obs- constructs. > There are very many programs which happen to do email, and email addresses in > particular, without having to fully understand message format. While true, I fail to see the relevance. Programs that don't need to parse messages will continue to not need to parse messages no matter what we say or do with the obsolete syntax. > > It might be tempting to try to carve out specific exceptions, such as saying > > that MUAs or MSAs are free to reject new messages that contain obs- constructs > > at the time of origination.   But mostly I think it's a Bad Idea to try to > > accommodate these exceptions, because there are exceptions to the exceptions. > > (like resending an old message, or forwarding an old message inside a new > > message). > Resending an old message should imply either wrapping it inside a > message/rfc822 attachment or reformatting it. First, resending/forwarding is not generating. The restrictions on message generation do not and should not apply. If this is in any unclear, it needs to clarified. The reason this is important is conversion of obsolete syntax to modern syntax in full generality is close to, if not actually, a gateway problem. Gateways are hard to code and even harder to code correctly. Absent a specification for how to do the conversion, this is not something we want to encourage. Second, the entire point of using message/rfc822 is to identify the message as a message so receiving agents can parse and process it properly. As such, it doesn't remove any requirement for processing obsolete syntax. If anything it's the exact opposite. > MUAs do reformat messages as > users edit them. Mediators reformat some header fields anyway, like > MIME-Version, Content-Transfer-Encoding. Yes, and one only has to look at some of the HTML that results from multiple MUAs having had a crack at the content to see what a wonderful idea this is. That said, composing a reply usually involves extraction of information from the original message. And in some cases, like extraction of addresses from message headers, this does necessitate a limited form of conversion form obsolete to modern syntax. However, while problems with address extraction are common, IME use of obsolete syntax has nothing to do with it. It's far more likely that something that's allowed by the current syntax like "ned.freed@mrochek.com" is going to cause a MUA to do Bad Things than, say, something like ned . freed@mrochek.com that is obsolete. In any case, the need for such conversion This is unfortunate, but nothing we say or do now is going to make the who knows how many billions of messages stored in archives go away. > I think if you need to resend a message, old or new, making sure that all of > its format is left intact, you're better off sealing it inside a zip. Hmm. Well, all I can say is I forward old messages pretty regularly to people for whom "zip" refers to something on their clothes. They are about as likely to be able to deal with a zip file unassisted as I am to run a marathon tomorrow. I doubt very much I'm alone in this. > > I strongly suspect that we're better off if there's a single grammar for > > parsing all email messages, regardless of presumed age, than to try to > > enumerate the specific cases in which an obs- construct should never > > appear. > We already have syntax compartments. For example, SMTP says: > for maximum interoperability, a host that expects to receive mail > SHOULD avoid defining mailboxes where the Local-part requires (or > uses) the Quoted-string form or where the Local-part is case- > sensitive. This falls far short of defining a compartment. In fact it really doesn't belong in the standard at all; it's the sort of thing that needs to be moved to the applicability statement. Ned From nobody Wed May 5 09:44:29 2021 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 B851F3A1859 for ; Wed, 5 May 2021 09:44:27 -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 8LCl1hw5G7zA for ; Wed, 5 May 2021 09:44:23 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 D56163A185C for ; Wed, 5 May 2021 09:44:22 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 745FD16059; Wed, 5 May 2021 18:44:19 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 108A410BE6; Wed, 5 May 2021 18:44:17 +0200 (CEST) Date: Wed, 05 May 2021 18:44:17 +0200 From: Steffen Nurpmeso To: Ned Freed Cc: Alessandro Vesely , emailcore@ietf.org Message-ID: <20210505164417.lmpjM%steffen@sdaoden.eu> In-Reply-To: <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> Mail-Followup-To: Ned Freed , Alessandro Vesely , emailcore@ietf.org User-Agent: s-nail v14.9.22-134-g4b1fe253bf-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 16:44:28 -0000 Ned Freed wrote in <01RYO4Z5MQQI0085YQ@mauve.mrochek.com>: |> On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: |>> On 5/4/21 5:36 PM, Dave Crocker wrote: ... |> Resending an old message should imply either wrapping it inside a |> message/rfc822 attachment or reformatting it. | |First, resending/forwarding is not generating. The restrictions on message |generation do not and should not apply. If this is in any unclear, \ |it needs to |clarified. I concur. We strictly only add Resend-* headers and ship the rest "as-is". (Having said that, it may change in the future when the software parses a mail as an object tree that is then "dumped to wire". But the current state is decade old behaviour, and things like DKIM etc. are built upon cheap production over plain RFC 5322 message format, if i understood and recall correctly, and as opposed to extraction of content-encodings and normalization.) ... |In any case, the need for such conversion This is unfortunate, but \ |nothing we |say or do now is going to make the who knows how many billions of messages |stored in archives go away. ... (I for one never understood the discussion as such. MUAs also have to face MBOX From_ lines with obscured mail addresses a bit in order to function, which is not even obsolete. And what is unclear about "obsolete", i always thought of that as, as has been said in this thread already, "do not generate, but could be seen in the wild".) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed May 5 09:48:31 2021 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 431D43A187C for ; Wed, 5 May 2021 09:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (2048-bit key) header.d=dcrocker.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 sHzfCgjsFkyX for ; Wed, 5 May 2021 09:48:24 -0700 (PDT) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 12BA03A187D for ; Wed, 5 May 2021 09:48:23 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2CFD0781DA3; Wed, 5 May 2021 16:48:22 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-16-49.trex.outbound.svc.cluster.local [100.96.16.49]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 9DBC7781A95; Wed, 5 May 2021 16:48:19 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.49 (trex/6.2.1); Wed, 05 May 2021 16:48:22 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Glossy-Soft: 389b82061c288d0f_1620233301864_3898309958 X-MC-Loop-Signature: 1620233301864:600542002 X-MC-Ingress-Time: 1620233301864 Received: from [192.168.0.111] (c-24-130-56-204.hsd1.ca.comcast.net [24.130.56.204]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 4EB8131DEB71; Wed, 5 May 2021 16:48:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1620233298; bh=y7Y+J/NqTvsAFYThHFQFmZD5rHxoLnnXh3DxCOq33xc=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=CAHOyNKByTTwCoX8hur81gPDs0tuB6x9ZjXzIpGDYvjaYt53JPkkNQaYdr9qlDlVy 7QJ4ZKAGu4F/nhNI/gAyqfN7G7u5wSojF9hcDyQSO5PbzsRM7wWZWVjYRmngUz7cEw YBpp+WpXVfI9pHGmc9J8sTd56VqiIcR0vOz/eo2ggFpHllU9IwYDX2v+cWsa60TUG4 BQiThhwcs9FcCJpm9Xt6mgnoIYCEdMJeo2tPQd6HUdC/70j89jab2bdWBSDn89EURx Sa9ZBgu5qmiVPvRZa0WD+CW2ilIJ4uHwNLwPBWxtv5ugZvpy+tpkGEeiMXLCxYCN3o MflV1eYGHwlhg== Reply-To: dcrocker@bbiw.net To: Ned Freed , Alessandro Vesely , emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <20210505164417.lmpjM%steffen@sdaoden.eu> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 5 May 2021 09:48:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210505164417.lmpjM%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 16:48:29 -0000 On 5/5/2021 9:44 AM, Steffen Nurpmeso wrote: > We strictly only add Resend-* headers and ship the rest > "as-is". ... > And what is > unclear about "obsolete", i always thought of that as, as has been > said in this thread already, "do not generate, but could be seen > in the wild".) Shipping text that conforms to the obs- rules is the same as generating that text. There is no systems-level distinction. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 5 11:23:11 2021 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 E71FE3A1BBE for ; Wed, 5 May 2021 11:23:09 -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 sZgdLA5jLLuf for ; Wed, 5 May 2021 11:23:05 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 EE23E3A1BBC for ; Wed, 5 May 2021 11:23:04 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 5EAD816059; Wed, 5 May 2021 20:23:00 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 93E0510BF0; Wed, 5 May 2021 20:22:57 +0200 (CEST) Date: Wed, 05 May 2021 20:22:57 +0200 From: Steffen Nurpmeso To: Dave Crocker Cc: Ned Freed , Alessandro Vesely , emailcore@ietf.org Message-ID: <20210505182257.CePAJ%steffen@sdaoden.eu> In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <20210505164417.lmpjM%steffen@sdaoden.eu> Mail-Followup-To: Dave Crocker , Ned Freed , Alessandro Vesely , emailcore@ietf.org User-Agent: s-nail v14.9.22-134-g4b1fe253bf-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 18:23:10 -0000 Dave Crocker wrote in : |On 5/5/2021 9:44 AM, Steffen Nurpmeso wrote: |> We strictly only add Resend-* headers and ship the rest |> "as-is". |... |> And what is |> unclear about "obsolete", i always thought of that as, as has been |> said in this thread already, "do not generate, but could be seen |> in the wild".) | |Shipping text that conforms to the obs- rules is the same as generating |that text. There is no systems-level distinction. To me.. I do not expect a RFC to represent literate programming in the sense of CWEB, but in the academic field cross-references, footnotes, indices and other forms of context seem higly respected and appreciated, i always rejoice when reading a book of Oxford University Press for example (Ivanhoe!) and so it is here. Leaving it all entirely up to some lonely ABNF (or wherever that sails to) near the end of a document may not be sufficient to understand the troubles programs could be faced with in real life. I admire a word of experience or context more than pages of the most detailed ABNF, even if contents are now hyperlinked (shall that be true). If you look at the list of roman emperors[1], ie the coins and busts, and compare from Augustus to Caracalla, and what comes thereafter .. and after, .. i do not see improvement and refinement by reduction, but only loss of culture and spirit. [1] https://en.wikipedia.org/wiki/List_of_Roman_emperors --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed May 5 11:34:35 2021 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 439A73A1C14 for ; Wed, 5 May 2021 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 DaZgz6m47V1J for ; Wed, 5 May 2021 11:34:28 -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 445BB3A1C11 for ; Wed, 5 May 2021 11:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1620239663; bh=n1SVu5LHHDRaTA7w9Lc+vO+OM5Cf9BcT5o5Quhh6jHk=; l=5051; h=To:Cc:References:From:Date:In-Reply-To; b=ASUnZlT9bJ6nq5er/vNmaqQuC9F6SIQXAGWureO8glRWv+dyfs9TtO1x+XHSTVFOV hY2f/5vZu89weJswguIc5iDL41Jb+pBJsHoQkZcdSer6S4ErYrQR60vib1XQ+Jxq2m bTvMRXIWqIk5Ww2hU29vBrEROcKYPCnVyw1ZJAdF0pDHUWDSdn4tvJCQcvXCv Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: emailcore@ietf.org Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC008.000000006092E52F.00001157; Wed, 05 May 2021 20:34:23 +0200 To: Ned Freed Cc: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> Date: Wed, 5 May 2021 20:34:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 18:34:33 -0000 On Wed 05/May/2021 17:05:31 +0200 Ned Freed wrote: >> On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: >>> On 5/4/21 5:36 PM, Dave Crocker wrote: >>> >>>> 2. Ale's note suggesting text attempts to distinguish interpreting archived >>>> messages versus incoming ones.  This draws am operationally bright line that >>>> has not been evident and might not be intended: >>>> >>>>      Email parsing for incoming mail is not required to support the >>>>      OBS-* rules. >>>> >>>> That's the operational effect of his language.  Is that really what folk find >>>> acceptable? >>> >>> I do not find it acceptable.   Quite the opposite, actually.  In general >>> conforming MUAs and most other mail handling programs need be able to parse >>> and deal with email messages containing obs- constructs. > >> There are very many programs which happen to do email, and email addresses in >> particular, without having to fully understand message format. > > While true, I fail to see the relevance. Programs that don't need to parse > messages will continue to not need to parse messages no matter what we say or do > with the obsolete syntax. A compliant MTA has to recognize and strip off source routes. But why should a web form that validates email addresses care about obs-angle-addr? >>> It might be tempting to try to carve out specific exceptions, such as saying >>> that MUAs or MSAs are free to reject new messages that contain obs- constructs >>> at the time of origination.   But mostly I think it's a Bad Idea to try to >>> accommodate these exceptions, because there are exceptions to the exceptions. >>> (like resending an old message, or forwarding an old message inside a new >>> message). >> >> Resending an old message should imply either wrapping it inside a >> message/rfc822 attachment or reformatting it. > > First, resending/forwarding is not generating.  The restrictions on message > generation do not and should not apply. If this is in any unclear, it needs to > clarified. That's clear. So is the observation that shipping text that conforms to the obs- rules is the same as generating that text. > The reason this is important is conversion of obsolete syntax to modern syntax > in full generality is close to, if not actually, a gateway problem. Gateways are > hard to code and even harder to code correctly. Absent a specification for how > to do the conversion, this is not something we want to encourage. I don't think one needs to convert obs- to current. Yet, if you tinker with obs- messages, some parts may happen to be converted. > Second, the entire point of using message/rfc822 is to identify the message as a > message so receiving agents can parse and process it properly. As such, it > doesn't remove any requirement for processing obsolete syntax. If anything > it's the exact opposite. On the one hand, a parser acting on email message attachment may happen to be applied on obsolete content. As such, it MUST be able to interpret obs- elements, according to the text I proposed, or, better, it SHOULD support the obs- elements, according to Dave's tweak. OTOH, we have MIME types for anything. How about message/obs-822? >> MUAs do reformat messages as >> users edit them.  Mediators reformat some header fields anyway, like >> MIME-Version, Content-Transfer-Encoding. > > Yes, and one only has to look at some of the HTML that results from multiple > MUAs having had a crack at the content to see what a wonderful idea this is. Agreed! >> I think if you need to resend a message, old or new, making sure that all of >> its format is left intact, you're better off sealing it inside a zip. > > Hmm. Well, all I can say is I forward old messages pretty regularly to people > for whom "zip" refers to something on their clothes. They are about as likely to > be able to deal with a zip file unassisted as I am to run a marathon tomorrow. :-) If you send that message to the Museum of Historical Mail Formats, they probably can deflate the zip. Otherwise, there is no point in striving to maintain the exact format the message had when it was sent at the time. >>> I strongly suspect that we're better off if there's a single grammar for >>> parsing all email messages, regardless of presumed age, than to try to >>> enumerate the specific cases in which an obs- construct should never >>> appear. > >> We already have syntax compartments.  For example, SMTP says: > >>     for maximum interoperability, a host that expects to receive mail >>     SHOULD avoid defining mailboxes where the Local-part requires (or >>     uses) the Quoted-string form or where the Local-part is case- >>     sensitive. > > This falls far short of defining a compartment. In fact it really > doesn't belong in the standard at all; it's the sort of thing that > needs to be moved to the applicability statement. It's still in rfc5321bis-02. Best Ale -- From nobody Wed May 5 11:41:11 2021 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 B1E153A1C52 for ; Wed, 5 May 2021 11:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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=messagingengine.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 2wBqhy60SYpK for ; Wed, 5 May 2021 11:41:05 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EE13A1C4B for ; Wed, 5 May 2021 11:41:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0D9BD1683 for ; Wed, 5 May 2021 14:40:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 05 May 2021 14:40:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WxFpvV4Vu5MR1jXvY7Ikp3PprYS4Zehqf6s4IiLwL PI=; b=O3NvLFrf0iHIs9BPLCMKNl0cUSTUQZurRLPcllHZRBwDqjes+NwGtbSoZ oBf4sotN9fluwpgz09f+0KSaiQwTQDnloxZDa09W/snzAOLl8uucW+8Duk+xsDMb sPahM9rbhHJSPzy1QTB6KrpkqPfCPJAdm4JCNCmHQYBrDuysMws9KOhCMoPXVSvJ gcIxYm/BOJkHrEIG6TOpj/ICsXW9Mrt1kCYi2sFiZCxZ1tqz2Kh5o8GF9jhZznWi BxNoSJwuucTAPhiSYr6mitx44GIlhHAGAStd0zTuvKlcXImig8NmboTuZRUIqqV1 aRRK0+cZo7mRmWeV/xnt68snnYEOQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefkedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedthe efgfefgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppeejfedr uddufedrudeiledriedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 5 May 2021 14:40:56 -0400 (EDT) To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> From: Keith Moore Message-ID: <4501e03e-925c-32dd-15e5-af6444d78fa7@network-heretics.com> Date: Wed, 5 May 2021 14:40:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 18:41:10 -0000 On 5/5/21 8:35 AM, Alessandro Vesely wrote: > On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: >> On 5/4/21 5:36 PM, Dave Crocker wrote: >> >>> 2. Ale's note suggesting text attempts to distinguish interpreting >>> archived messages versus incoming ones.  This draws am operationally >>> bright line that has not been evident and might not be intended: >>> >>>      Email parsing for incoming mail is not required to support the >>>      OBS-* rules. >>> >>> That's the operational effect of his language.  Is that really what >>> folk find acceptable? >> >> I do not find it acceptable.   Quite the opposite, actually.  In >> general conforming MUAs and most other mail handling programs need be >> able to parse and deal with email messages containing obs- constructs. > > There are very many programs which happen to do email, and email > addresses in particular, without having to fully understand message > format. Yes, that's true.   Many things can be properly implemented without having to do any significant parsing.    I guess I should say instead that mail handling programs should not break or incorrectly implement a feature because a message contains obs- constructs. >> It might be tempting to try to carve out specific exceptions, such as >> saying that MUAs or MSAs are free to reject new messages that contain >> obs- constructs at the time of origination.   But mostly I think it's >> a Bad Idea to try to accommodate these exceptions, because there are >> exceptions to the exceptions.  (like resending an old message, or >> forwarding an old message inside a new message). > > > Resending an old message should imply either wrapping it inside a > message/rfc822 attachment or reformatting it.  MUAs do reformat > messages as users edit them.  Mediators reformat some header fields > anyway, like MIME-Version, Content-Transfer-Encoding. > > I think if you need to resend a message, old or new, making sure that > all of its format is left intact, you're better off sealing it inside > a zip. Emphatically disagree.    We should not be trying to change how people use email, or disable features that people have long found valuable.  And there are sometimes good reasons for leaving the original message format intact, such as when you receive a complex message that has been misdirected and you want to send it to the right place.   A resent message and a forwarded message are semantically different, and forwarding when you mean to resend degrades the message.   Also some UAs still don't read attached messages as functionally as they do top-level messages - they might not implement reply to an attached message, for instance. >> I strongly suspect that we're better off if there's a single grammar for >> parsing all email messages, regardless of presumed age, than to try to >> enumerate the specific cases in which an obs- construct should never >> appear. > > We already have syntax compartments.  For example, SMTP says: > >    for maximum interoperability, a host that expects to receive mail >    SHOULD avoid defining mailboxes where the Local-part requires (or >    uses) the Quoted-string form or where the Local-part is case- >    sensitive. I thought we were talking about the message format, not best operational practice for assigning mailbox names. More generally, what an implementation should support is a very different topic than what we'd recommend that an operator do. > Hosts that expect to receive messages is an operational category akin > to the one of messages that expect to be sent. disagree. > >>> This, of course, suggests that the distinction between incoming and >>> archive is a convenient -- but problematic -- myth, since there is >>> no obvious labeling of mail to distinguish what version of the >>> specification it conforms to. >> >> IMO it's not even a convenient myth, since believing in the myth >> causes more problems than it solves. > > > Obsolete messages don't have to be a myth.  Yet they exist. Mostly disagree.   We've never declared a particular kind of message to be obsolete, and as a practical matter every decent MUA needs to be able to deal with old messages.   I might well consider rfc733 messages to be obsolete, since none of the updates to rfc822 ever required support for "user at host" addresses. But (nearly) anything that conforms to RFC822 and later should still be supported, to the extent feasible.   We don't expect pre-DNS hostnames to work, or DNS names that no longer are in DNS to be resolvable.  But that doesn't make the messages unreadable. Maybe we really do need to change the obs- symbols in the ABNF to clarify this situation. Keith From nobody Wed May 5 13:31:14 2021 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 29E4F3A2001 for ; Wed, 5 May 2021 13:31:12 -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 j1Ar4qTV0mfm for ; Wed, 5 May 2021 13:31:07 -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 53A7F3A1FFC for ; Wed, 5 May 2021 13:31:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYOENLJLC000G2TP@mauve.mrochek.com> for emailcore@ietf.org; Wed, 5 May 2021 13:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620246363; bh=7XYZUnqwpBxFDLoMlzBtcaGWKeeaE1vJFKGbkNiVBoc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=UjitcJeKzl37pWq8WNTXGvV8GVsVP7PXg/0ar+jZtCAjYdsr7eByq5B35hCIovqwl PNm1JpcOT8PH0j52xicOhHsFFXwRuEpAaGHmS1ebrLUqJfYl4GHAtmnP++s4YvfjtR IJwDjsF3tOhJDH813zIoWtR1LMA3Lk0Jlc5wIf1w= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Wed, 5 May 2021 13:26:00 -0700 (PDT) Cc: Ned Freed , Alessandro Vesely , emailcore@ietf.org Message-id: <01RYOENJ0JQE0085YQ@mauve.mrochek.com> Date: Wed, 05 May 2021 13:18:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 May 2021 09:48:13 -0700" References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <20210505164417.lmpjM%steffen@sdaoden.eu> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 20:31:12 -0000 > On 5/5/2021 9:44 AM, Steffen Nurpmeso wrote: > > We strictly only add Resend-* headers and ship the rest > > "as-is". > ... > > And what is > > unclear about "obsolete", i always thought of that as, as has been > > said in this thread already, "do not generate, but could be seen > > in the wild".) > Shipping text that conforms to the obs- rules is the same as generating > that text. There is no systems-level distinction. Absolutely, and that is the reason why transport agents have to be able to accept obsolete syntax. But this isn't why we restrict newly generated material to a subset of the overall syntax. We do that because we believed generating only this subset improves overall interoperability. In hindsight I wish we had been a bit more, um, liberal in what we chose to move to the obsolete side of things. But that's water under the bridge, and given the charter of this group the focus needs to be on how best to describe the syntax we have. Ned From nobody Wed May 5 16:14:31 2021 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 5BA733A25A6 for ; Wed, 5 May 2021 16:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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_FILL_THIS_FORM_SHORT=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=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 ZpuEZc3skj1O for ; Wed, 5 May 2021 16:14:24 -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 B90E43A25A1 for ; Wed, 5 May 2021 16:14:24 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYOD645REO00HMWM@mauve.mrochek.com> for emailcore@ietf.org; Wed, 5 May 2021 12:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620243822; bh=yocRWxIwg7KVra+fbaDlBzgcUwfNsWmQXl/wYDrHS4o=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=QaCynr598M8YSuPfuMPR5U+7miOhlKK4+2iB4kmdt+pbhPYHj/bbI1fPYzb6rs2cS hds7WQAgI2df/v+VhH0ut3FIg0P6+91jcs2XCO8ZJtLpMFkn/Qrmv9BcdhjOCOfR1n nDZdNv/Lq9fXqJt0RvC43CYylfWnLXVtIN+lFgyQ= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Wed, 5 May 2021 12:43:40 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RYOD6255T80085YQ@mauve.mrochek.com> Date: Wed, 05 May 2021 11:54:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 May 2021 20:34:23 +0200" <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Wed, 05 May 2021 23:14:29 -0000 > On Wed 05/May/2021 17:05:31 +0200 Ned Freed wrote: > >> On Wed 05/May/2021 00:20:21 +0200 Keith Moore wrote: > >>> On 5/4/21 5:36 PM, Dave Crocker wrote: > >>> > >>>> 2. Ale's note suggesting text attempts to distinguish interpreting archived > >>>> messages versus incoming ones.  This draws am operationally bright line that > >>>> has not been evident and might not be intended: > >>>> > >>>>      Email parsing for incoming mail is not required to support the > >>>>      OBS-* rules. > >>>> > >>>> That's the operational effect of his language.  Is that really what folk find > >>>> acceptable? > >>> > >>> I do not find it acceptable.   Quite the opposite, actually.  In general > >>> conforming MUAs and most other mail handling programs need be able to parse > >>> and deal with email messages containing obs- constructs. > > > >> There are very many programs which happen to do email, and email addresses in > >> particular, without having to fully understand message format. > > > > While true, I fail to see the relevance. Programs that don't need to parse > > messages will continue to not need to parse messages no matter what we say or do > > with the obsolete syntax. > A compliant MTA has to recognize and strip off source routes. But why should a > web form that validates email addresses care about obs-angle-addr? I'm skeptical that most web forms accept anything beyond addr-spec, but even so, I take your point: While it seems unlikely that J. Random User is going to directly enter an obsolete syntax address as anything other than a mistake, people can and do cut and paste from various sources. And addr-spec has its own obsolete elements. My immediate thought would be to try and cover this point in the applicability statement: What piece of grammer is appropriate for a web form accepting an email address to use? > >>> It might be tempting to try to carve out specific exceptions, such as saying > >>> that MUAs or MSAs are free to reject new messages that contain obs- constructs > >>> at the time of origination.   But mostly I think it's a Bad Idea to try to > >>> accommodate these exceptions, because there are exceptions to the exceptions. > >>> (like resending an old message, or forwarding an old message inside a new > >>> message). > >> > >> Resending an old message should imply either wrapping it inside a > >> message/rfc822 attachment or reformatting it. > > > > First, resending/forwarding is not generating.  The restrictions on message > > generation do not and should not apply. If this is in any unclear, it needs to > > clarified. > That's clear. So is the observation that shipping text that conforms to the > obs- rules is the same as generating that text. I'm afraid I have to disagree. It's completely inappropriate to apply generating rules to a forwarded messsage within that text, for example. The term "generate" is used for a reason: It applies to stuff you *generate*. The relationship of MIME to obsolete syntax is definitely something that will need to be covered in any future revision of MIME. > > The reason this is important is conversion of obsolete syntax to modern syntax > > in full generality is close to, if not actually, a gateway problem. Gateways are > > hard to code and even harder to code correctly. Absent a specification for how > > to do the conversion, this is not something we want to encourage. > I don't think one needs to convert obs- to current. Yet, if you tinker with > obs- messages, some parts may happen to be converted. You do if you believe everything you submit to the transport infrastructure has to be treated as if you generated it. > > Second, the entire point of using message/rfc822 is to identify the message as a > > message so receiving agents can parse and process it properly. As such, it > > doesn't remove any requirement for processing obsolete syntax. If anything > > it's the exact opposite. > On the one hand, a parser acting on email message attachment may happen to be > applied on obsolete content. As such, it MUST be able to interpret obs- > elements, according to the text I proposed, or, better, it SHOULD support the > obs- elements, according to Dave's tweak. > OTOH, we have MIME types for anything. How about message/obs-822? An interesting idea, and had the obs concept existed at the time MIME was created I for one would have given it serious consideration. Unfortunately that was never possible given that MIME (RFCs 1341-1342) significantly predate the first revision of the message format and SMTP documents (RFC 2821-2822). Given the cost and benefits, I don't think a strong enough case can be made at this late date for adding such a type. FWIW, IME message/global uptake hasn't been all that great, and the reasons for a separate type there are pretty compelling. > >> MUAs do reformat messages as > >> users edit them.  Mediators reformat some header fields anyway, like > >> MIME-Version, Content-Transfer-Encoding. > > > > Yes, and one only has to look at some of the HTML that results from multiple > > MUAs having had a crack at the content to see what a wonderful idea this is. > Agreed! > >> I think if you need to resend a message, old or new, making sure that all of > >> its format is left intact, you're better off sealing it inside a zip. > > > > Hmm. Well, all I can say is I forward old messages pretty regularly to people > > for whom "zip" refers to something on their clothes. They are about as likely to > > be able to deal with a zip file unassisted as I am to run a marathon tomorrow. > :-) > If you send that message to the Museum of Historical Mail Formats, they > probably can deflate the zip. Otherwise, there is no point in striving to > maintain the exact format the message had when it was sent at the time. Now you have me thinking about the message format used once upon a time by Sun workstations, which tar'ed up the parts. Or the one used by NeXT computers, which used some flavor of zip. And Microsoft's TNEF, of course. Never forget TNEF. There's stuff out there that still sends it. > >>> I strongly suspect that we're better off if there's a single grammar for > >>> parsing all email messages, regardless of presumed age, than to try to > >>> enumerate the specific cases in which an obs- construct should never > >>> appear. > > > >> We already have syntax compartments.  For example, SMTP says: > > > >>     for maximum interoperability, a host that expects to receive mail > >>     SHOULD avoid defining mailboxes where the Local-part requires (or > >>     uses) the Quoted-string form or where the Local-part is case- > >>     sensitive. > > > > This falls far short of defining a compartment. In fact it really > > doesn't belong in the standard at all; it's the sort of thing that > > needs to be moved to the applicability statement. > It's still in rfc5321bis-02. A move should be considered, since it's clearly interoperability advice. Ned From nobody Wed May 5 18:49:37 2021 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 DF7793A2AA4 for ; Wed, 5 May 2021 18:49:35 -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 QpiDiFqDQtDk for ; Wed, 5 May 2021 18:49:31 -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 60F473A2AA3 for ; Wed, 5 May 2021 18:49:31 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1leT8l-0009Qk-AN; Wed, 05 May 2021 21:49:23 -0400 Date: Wed, 05 May 2021 21:49:17 -0400 From: John C Klensin To: Ned Freed , Alessandro Vesely cc: emailcore@ietf.org Message-ID: In-Reply-To: <01RYOD6255T80085YQ@mauve.mrochek.com> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.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] 'obsolete' considered misleading 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: Thu, 06 May 2021 01:49:36 -0000 --On Wednesday, May 5, 2021 11:54 -0700 Ned Freed wrote: >... >> A compliant MTA has to recognize and strip off source routes. >> But why should a web form that validates email addresses care >> about obs-angle-addr? =20 > I'm skeptical that most web forms accept anything beyond > addr-spec, but even so, I take your point: While it seems > unlikely that J. Random User is going to directly enter an > obsolete syntax address as anything other than a mistake, > people can and do cut and paste from various sources. > And addr-spec has its own obsolete elements. And, based on purely anecdotal observations (but many of them), the far bigger problem with sloppily designed or implemented web forms involves rejecting as "invalid addresses" strings that contain perfectly valid characters. The most frequent problems seem to involve "+", but I've seen issues with "=3D", "/", and even "." to say nothing of assorted constructions using quotes and assumptions that local parts are case insensitive (see below for more about that). None of that interacts with so-called obsolete forms or "obs-" syntax productions, but I think all they lead to the same place, specifically...=20 =20 > My immediate thought would be to try and cover this point in > the applicability statement: What piece of grammer is > appropriate for a web form accepting an email address to use? Either couched as web form-specific or as a section about common mistakes, the problems they cause, and how competent implementations deal with them. While web forms pose special "opportunities" as you and others have pointed out, most of the problems can be encountered by MUAs that are trying to adapt to copying or pasting bits of syntax from ancient or fussy messages (or elderly users with what we now consider bad habits). FWIW, you may remember that I/we tried to address some of the same issues in RFC 3696. While I'd rate that document as a resounding failure, using bits of the portions of it that would fall into this WG's scope as a starting point for some of the A/S and then obsoleting all or part of that old effort would probably be helpful. >... >> > The reason this is important is conversion of obsolete >> > syntax to modern syntax in full generality is close to, if >> > not actually, a gateway problem. Gateways are hard to code >> > and even harder to code correctly. Absent a specification >> > for how to do the conversion, this is not something we want >> > to encourage. >=20 >> I don't think one needs to convert obs- to current. Yet, if >> you tinker with obs- messages, some parts may happen to be >> converted. >=20 > You do if you believe everything you submit to the transport > infrastructure > has to be treated as if you generated it. And the reality is that, absent either treating every instance of obs- as a gateway situation (as you pointed out) and/or the arrival of the protocol police, implementations will handle the edge cases however they handle them. It would be nice to expect complete consistency but it is unrealistic. And, even if the protocol police show up, implementations that decide to transmit the obs- stuff will just say "well, they have to accept it, so we are not _really_ doing anything wrong. Been there... all too many times and I'm sure you and others have too. My conclusion is that making significant changes is likely to create more confusion and cause more problems than the changes will actually solve. It would give us additional ability to point to particular implementers and their users and say "you are a non-conforming evildoer", but the historical evidence suggests that the worst offenders won't care. Trying to split hairs to get the explanations exactly right just won't help ... and I certainly hope the WG has more important issues to spend time on. =20 And that, I think, takes us back to where we were a while ago, only, I hope, with more understanding of what the A/S should say (and I hope someone is making notes). Specifically, 5322bis gets a paragraph explaining our poor choice of terminology and then we move on, concentrating on explanations of good behavior, bad behavior, and the risks of the latter in the A/S. >... >> >> I think if you need to resend a message, old or new, >> >> making sure that all of its format is left intact, you're >> >> better off sealing it inside a zip. >> >=20 >> > Hmm. Well, all I can say is I forward old messages pretty >> > regularly to people for whom "zip" refers to something on >> > their clothes. They are about as likely to be able to deal >> > with a zip file unassisted as I am to run a marathon >> > tomorrow. To say nothing of the anti-malware systems who think that the only reason to send a compressed file or archive is get assorted forms of evil past them. If one of those intervenes, the users of whom you speak are likely to not see the message at all unless they make a habit of searching trash folders for things that they might have expected by can't decode. >... >> If you send that message to the Museum of Historical Mail >> Formats, they probably can deflate the zip. Otherwise, there >> is no point in striving to maintain the exact format the >> message had when it was sent at the time. > Now you have me thinking about the message format used once > upon a time by Sun workstations, which tar'ed up the parts. Or > the one used by NeXT computers, which used some flavor of zip. > And Microsoft's TNEF, of course. Never forget TNEF. There's > stuff out there that still sends it. All problems MIME was supposed to solve/ eliminate, of course. NeXT and Sun may have taken care of themselves, but I received a message that was dependent of TNEF last week. I have observed that facing in the direction of Redmond, pointing one or more fingers, and shouting "evil violation of standards" has not been successful in bringing about improvements or even in getting the messages decoded. >> >>> I strongly suspect that we're better off if there's a >> >>> single grammar for parsing all email messages, regardless >> >>> of presumed age, than to try to enumerate the specific >> >>> cases in which an obs- construct should never appear. >> >=20 >> >> We already have syntax compartments.=C2=A0 For example, = SMTP >> >> says: >> >=20 >> >> =C2=A0=C2=A0=C2=A0 for maximum interoperability, a host = that expects >> >> to receive mail =C2=A0=C2=A0=C2=A0 SHOULD avoid defining = mailboxes >> >> where the Local-part requires (or =C2=A0=C2=A0=C2=A0 uses) = the >> >> Quoted-string form or where the Local-part is case- = =C2=A0=C2=A0=C2=A0 >> >> sensitive. >> >=20 >> > This falls far short of defining a compartment. In fact it >> > really doesn't belong in the standard at all; it's the sort >> > of thing that needs to be moved to the applicability >> > statement. >=20 >> It's still in rfc5321bis-02. >=20 > A move should be considered, since it's clearly > interoperability advice. Concur. It is definitely not the only text in 5321/5321bis that was put there to keep people out of trouble with others who fail to carefully follow the specs. Without looking, I'm not sure how many of those cases can be identified and moved to another document in a surgically clean way. If, as I expect, the answer turns out to be "some but not all", the WG will need to decide what to do about that and, in particular, whether it is ok to fix the easy ones and leave the others (including the ones no one spots and calls out). But, in principle, I'd be happy to have every bit of it taken out and moved to the A/S. best, john From nobody Wed May 5 19:27:09 2021 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 43C5F3A2BCD for ; Wed, 5 May 2021 19:27:08 -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 U5Fcuqk8KlXq for ; Wed, 5 May 2021 19:27:04 -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 E2A243A2BD1 for ; Wed, 5 May 2021 19:27:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1leTjA-0009WG-OI; Wed, 05 May 2021 22:27:00 -0400 Date: Wed, 05 May 2021 22:26:54 -0400 From: John C Klensin To: Keith Moore , emailcore@ietf.org Message-ID: In-Reply-To: <4501e03e-925c-32dd-15e5-af6444d78fa7@network-heretics.com> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <4501e03e-925c-32dd-15e5-af6444d78fa7@network-heretics.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: [Emailcore] SMTP "maximum interoperability" language (was: Re: 'obsolete' considered misleading) 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: Thu, 06 May 2021 02:27:08 -0000 Hi. I have already semi-covered this, but want to address a different part of it and use a new subject line to keep it from getting lost. --On Wednesday, May 5, 2021 14:40 -0400 Keith Moore wrote: >... >> We already have syntax compartments.=C2=A0 For example, SMTP = says: >>=20 >> =C2=A0=C2=A0 for maximum interoperability, a host that = expects to >> receive mail =C2=A0=C2=A0 SHOULD avoid defining mailboxes = where the >> Local-part requires (or =C2=A0=C2=A0 uses) the Quoted-string = form or >> where the Local-part is case- =C2=A0=C2=A0 sensitive. >=20 > I thought we were talking about the message format, not best > operational practice for assigning mailbox names. And that comment is not a syntax compartment or really about syntax at all. It does absolutely nothing to change the requirements that implementations support full Quoted-string syntax and case-sensitive local parts. Perhaps there should be been more explanation, but what is does -- all it does -- is to tell mail host operators (not SMTP implementers) that there are things out there (enough of them to be a problem) that do not understand the subtleties associated with those forms and so, depending on them is probably a bad idea. If I (or the WG, had been inclined to write more test, we would even have explained that, e.g.,=20 treating FooL@example.com as different from fool@example.com and rejecting one of them as a bad address is probably undesirable but treating them as separate addresses and routing them to different mailboxes (and probably people) is likely worse. And, in that context, the "things" that can get confused are not just mail system implementations. They can be other software entirely (including web forms) or even human-type users. Per the other note, this really is A/S material buried in the Technical Specification. It is not unusual to combine the two, so doing so in 5321 and its predecessors is not some sort of error, but, if we are doing a separate A/S document, it may make sense to move some or all statements of that sort. I don't know if it is all a candidate for moving to the A/S (see the comments in my earlier note about surgically clean removal), but it is worth noting that all of Section 7.8 of RFC 5321 (and, so far, draft-ietf-emailcore-rfc5321bis) is also about operations and configuration choices. It does not change the requirements for an implementation except in one way that is only implicit: that language suggests that smart implementers will design enough configuration options or "knobs" into their implementations to either automate the sorts of adjustments that section specifies, allow making them on a per-host or per-installation basis (ideally in real time rather than forcing the SMTP code to be restarted), or both. Should that have been more clear? Perhaps although the argument against it is that SMTP is supposed to be about what happens on the wire rather than the fine details of implementations. > More generally, what an implementation should support is a > very different topic than what we'd recommend that an operator > do. Exactly. best, john From nobody Thu May 6 19:23:23 2021 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 2FBCF3A0C0E for ; Thu, 6 May 2021 19:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 hiWDK1rwnN6y for ; Thu, 6 May 2021 19:23:16 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 851C53A0BED for ; Thu, 6 May 2021 19:21:58 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id j11so5627359qtn.12 for ; Thu, 06 May 2021 19:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ncsHGhGjISvXB5wsVmUJBj9HOpW6VhCccv33LL04DrQ=; b=YfvZT0hiCWm5tH0FmRuunF3880OTQPSC2vTtN7hRfG8KcySWQrwn+FuCsi5Sihf/Rg 98GETK/cCynPJ/h4QMRAqHCynD8E+kS9HcwfN7YdaXy+mfztDrJHUGDKvUO6BCMYQvoo RDrKDV1e+aBFcJ8QfLmcnYe65W9Yc1aIt1bl+UrKFtceSBfPxxNuJO3jz6km6POczSdk zlhjxrZsuIszTK/jtYreYA+3Ay/0Az1dNJzNi4lJmxK7ZandtbvTvreX/OAbYLzSCCj0 GURC94iDMmhyy9JvHVs8Ob6ihWviW828lK1ABEvjBBgUk6rO2IiiDGs1CBTMFxLjrOV7 NrBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ncsHGhGjISvXB5wsVmUJBj9HOpW6VhCccv33LL04DrQ=; b=dWGrRhxxcImV7cqyWxTkMTSVOdobbv6rHV37Y8Qx4m0ScYihj/UDW9+YARLX4hnxkp IlrqxbI6AepYChIPpk/VlX2fsDNYzX0c2E1BsPIkj/nwymEVymGdEn/WO7QDhQirplm1 CnW9l9fVlccSmYPwFryGotweBvHg34AhepJpfOn6B+lIofpPN0j27X2xKPccUioSdmog 86MfNuUIbwvKXE1uRatj/tgi/mqD4pNapSkQCWMUMCl8uXsmUsW4MuZPvjVJBbxWl6jU 0zjNFwKgbkcbJFNBh7w4sRNCMte3YzoTLGxUnKHj5oqjbdMeJz6PxsgAcFhN8iCyxe5m el/Q== X-Gm-Message-State: AOAM531f5ZxRNYc/wlnxkDQYbYowf7/YvCwp1EB8CrcGEItssTQG0alo Jv0vOsikRWk5yxBfAVWe2ORkbALhe1EBQVhEeyqUCVPCI1vIWA== X-Google-Smtp-Source: ABdhPJzimM8u2tQLTmAp4+JnqPvIvDaZIpoGnmDTlYsZLoEulXVjgTq+In1c+cE2CeKeUUD8S37/+CPnuxQnRZaLa8Y= X-Received: by 2002:a05:622a:1353:: with SMTP id w19mr7136388qtk.220.1620354116268; Thu, 06 May 2021 19:21:56 -0700 (PDT) MIME-Version: 1.0 References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> In-Reply-To: From: Todd Herr Date: Thu, 6 May 2021 22:21:40 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000082cc0f05c1b4174e" Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 02:23:21 -0000 --00000000000082cc0f05c1b4174e Content-Type: text/plain; charset="UTF-8" As chair... It seems we were close to consensus earlier this week on the idea of adding some text to section 1.2.3 explaining that "obsolete" wasn't really the correct word to use, with a back reference to it in section 4, but now the thread has wandered off that path. I'm going to try to bring it back to the path, because I think the thread has run its course, and I'd like to bring this to a conclusion and move on. Let me propose some text to see if we can't nudge this across the line. Here is the current paragraph from section 1.2.3: Section 4 of this document specifies an "obsolete" syntax. There are references in section 3 to these obsolete syntactic elements. The rules of the obsolete syntax are elements that have appeared in earlier versions of this specification or have previously been widely used in Internet messages. As such, these elements MUST be interpreted by parsers of messages in order to be conformant to this specification. However, since items in this syntax have been determined to be non-interoperable or to cause significant problems for recipients of messages, they MUST NOT be generated by creators of conformant messages. And I propose as a starting point adding the following paragraph after that one: Note: The dictionary definition of "obsolete" is "no longer in use or no longer useful". While this specification mandates that these syntactic elements no longer be generated, it also mandates that conformant parsers be able to support them. The reason for this latter requirement is that there are long-established sites on the internet with mail archives that go back decades, archives with messages containing these elements. While these archives may only be mined occasionally, they are nonetheless still in use, making "obsolete" the incorrect term to describe these elements. Later efforts to revise this specification contemplated changing the term to "legacy" or something that would more accurately describe the elements, but such a change was rejected due to fears that it would result in unnecessary confusion, especially among long-time users and implementers of the specification. Have at it... -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000082cc0f05c1b4174e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As chair...

It seems we were close to consen= sus earlier this week on the idea of adding some text to section 1.2.3 expl= aining that "obsolete" wasn't really the correct word to use,= with a back reference to it in section 4, but now the thread has wandered = off that path. I'm going to try to bring it back to the path, because I= think the thread has run its course, and I'd like to bring this to a c= onclusion and move on.

Let me propose some text to see if we can't n= udge this across the line.

Here is the current paragraph from secti= on 1.2.3:

=C2=A0 =C2=A0Section 4 of this document = specifies an "obsolete" syntax.=C2=A0 There are

<= div>

=C2=A0=C2=A0 references in section 3 to these obsolete syntactic elements.=C2=A0 The

<= /div>

=C2=A0=C2= =A0 rules of the obsolete syntax are elements that have appeared in<= /font>

<= p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-v= ariant-east-asian:normal;font-stretch:normal;line-height:normal;color:rgb(0= ,0,0)">=C2=A0=C2=A0 earlier versions of this specification or = have previously been widely

=C2=A0=C2=A0 used in Intern= et messages.=C2=A0 As su= ch, these elements MUST be

=C2=A0=C2=A0 interpreted by = parsers of messages in order to be conformant to this

=C2=A0= =C2=A0 specification.=C2= =A0 However, since items in this syntax have been

<= /div>

=C2= =A0=C2=A0 determined to be non-interoperable or to cause significant= problems

=C2=A0=C2=A0 for recipients of messages, they= MUST NOT be generated by creators of

=C2=A0=C2=A0 conf= ormant messages.


And I pro= pose as a starting point adding the following paragraph after that one:


=C2=A0=C2=A0 = Note: The dictionary definition of "obsolete" is "no = longer in use or=C2=A0

=C2=A0=C2=A0 no longer useful". While this specific= ation mandates that these syntactic

=C2=A0=C2=A0 elem= ents no longer be generated, it also mandates that conformant parsers=C2=A0

=

=C2=A0=C2= =A0 be able to support them. The reason for this latter requirement = is that =C2=A0

= =C2=A0=C2=A0 there are long-established sites on the internet = with mail archives that=C2=A0

=C2=A0=C2=A0 go back decades, archives with mess= ages containing these elements. While=C2=A0

=C2=A0=C2=A0 these archives may onl= y be mined occasionally, they are nonetheless still=C2=A0

=C2=A0=C2=A0 in use, = making "obsolete" the incorrect term to describe these elements.<= span class=3D"gmail-Apple-converted-space">=C2=A0

<= /div>

=C2= =A0=C2=A0 Later efforts to revise this specification contemplated ch= anging the term=C2=A0

=C2=A0=C2=A0 to "legacy" or something that woul= d more accurately describe the elements,=C2=A0

=C2=A0 =C2=A0but such a change was rejected due to=C2=A0fears that it would result in=C2= =A0

=C2=A0 =C2=A0unnecessary confusion, especially= among=C2=A0long-time users and implementers of=C2=A0

=C2=A0 =C2=A0the specification.


Have at it...
<= br>
--

Todd Herr | Sr.= Technical Program Manager
=
m: 703.220.4153
=

This email an= d all data transmitted with it contains confidential and/or proprietary inf= ormation intended solely for the use of individual(s) authorized to receive= it. If you are not an intended and authorized recipient you are hereby not= ified of any use, disclosure, copying or distribution of the information in= cluded in this transmission is prohibited and may be unlawful. Please immed= iately notify the sender by replying to this email and then delete it from = your system.

--00000000000082cc0f05c1b4174e-- From nobody Thu May 6 19:26:12 2021 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 A5AE03A0C3A for ; Thu, 6 May 2021 19:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.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 EASPiJsAQaTj for ; Thu, 6 May 2021 19:26:06 -0700 (PDT) Received: from cheetah.ash.relay.mailchannels.net (cheetah.ash.relay.mailchannels.net [23.83.222.34]) (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 1DB233A0C38 for ; Thu, 6 May 2021 19:26:04 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 23680341E38; Fri, 7 May 2021 02:26:00 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-17-237.trex.outbound.svc.cluster.local [100.96.17.237]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id AA72F34196E; Fri, 7 May 2021 02:25:58 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.17.237 (trex/6.2.1); Fri, 07 May 2021 02:25:59 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Squirrel-Duck: 61e20a77737f7c47_1620354359712_3341830104 X-MC-Loop-Signature: 1620354359711:2136640620 X-MC-Ingress-Time: 1620354359711 Received: from [192.168.0.111] (c-24-130-56-204.hsd1.ca.comcast.net [24.130.56.204]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 81442226938C; Fri, 7 May 2021 02:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1620354357; bh=TxY3yQz/xw/gUuQ8nkQfDu4FOx/S1YEHJQpLAx15oEQ=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=j6drVkhScjCEherXZ3CRfnUeTQ/T73Ydt2RP7pQQ119f6LoWpPP3YiQgyOOFq/t07 gk1Npy0GUPjfpPMaaoIqYrpdIhQQLtzVQYqVbWOC/clG7Wl6Su/jL/j2WNtTNgTUvL E9SoX1D9WtQSFIkd5wQlYW447J0eAPIWnPc3zuQ4KNK79oaTvAHpJn4C07ZOT8n0RG gM7bfNiJMU40g3dw0pjgt1hu1e+YqAO/ZfcaX6QNAF/pSfGD+uIT2XHVDqqmIqv/+1 cukjDHgB+o31Zb617rqH2p39pPfL31YOQX2AsT08zYUU9vZfGXiYgF5K7vehLgiTLb AmWJFUv5roHnQ== Reply-To: dcrocker@bbiw.net To: Todd Herr , emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9ce5eb1a-1e6b-2feb-4ada-7a0757dd919b@dcrocker.net> Date: Thu, 6 May 2021 19:25:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 02:26:11 -0000 On 5/6/2021 7:21 PM, Todd Herr wrote: > Have at it... Your proposed text is quite good. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu May 6 20:31:36 2021 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 F14B43A11DE for ; Thu, 6 May 2021 20:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 tWPebcQih_s4 for ; Thu, 6 May 2021 20:31:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DF53A11E5 for ; Thu, 6 May 2021 20:31:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A4496FA4 for ; Thu, 6 May 2021 23:31:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 06 May 2021 23:31:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ur/H0h uhIywAoQ9zT3enwRkKMbLzcmdOybgB7DzP0iI=; b=IvS0BOQ7soEfevrqD8n2ZV 7ZgoqcfjQ+uYZ8Qcca4QVIJ/uiMtzc1ydbS00cCvBxmKjdZPnlM0v5O3L92IBDQk iRxln0252+QkIQsY97khDQ6CKUlAPrMkRI+LlFI3YxhTHwHXGb7CDfWQRQaZtmWR vKOv0/GEgSYp3Obg4ExDPD5ExcpL73KNEkw2Kkr3bk0sm9KdEZjwFhdp2lyBcLAG 1VJSUb0xOtJMG+SuwyR0Gf1aWM2ek86qUVtlKVubwPBWXro1cqhVN3a37mLopujN zB3jBe6YBlLsJExs0aaPGIssinSWuNxm3y15JQgRRtuT/B3c7wM6L0g+f+owQTjw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeguddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepveefteduieegtd elvddvtddufeejjeffvdefteejieeulefgtdfggedtffektedunecukfhppedvfedruddv gedruddtrddujedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.121] (23-124-10-170.lightspeed.knvltn.sbcglobal.net [23.124.10.170]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 6 May 2021 23:31:16 -0400 (EDT) To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> From: Keith Moore Message-ID: <7185b017-7b29-36b9-038c-fa28e84f7319@network-heretics.com> Date: Thu, 6 May 2021 23:31:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12A5D1D9DA3D60F1D71BEA9A" Content-Language: en-US Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 03:31:35 -0000 This is a multi-part message in MIME format. --------------12A5D1D9DA3D60F1D71BEA9A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/6/21 10:21 PM, Todd Herr wrote: > Note: The dictionary definition of "obsolete" is "no longer in use or > > no longer useful". While this specification mandates that these > syntactic > > elements no longer be generated, it also mandates that conformant > parsers > > be able to support them. The reason for this latter requirement is > that > > there are long-established sites on the internet with mail > archives that > > go back decades, archives with messages containing these elements. > While > > these archives may only be mined occasionally, they are > nonetheless still > > in use, making "obsolete" the incorrect term to describe these > elements. > > Later efforts to revise this specification contemplated changing > the term > > to "legacy" or something that would more accurately describe the > elements, > >  but such a change was rejected due tofears that it would result in > >  unnecessary confusion, especially amonglong-time users and > implementers of > >    the specification. > > Suggest instead: Note: The dictionary definition of "obsolete" is "no longer in use or no longer useful". While this specification mandates that these syntactic elements no longer be generated, it also mandates that conformant parsers be able to support them. One reason for this latter requirement is that ^^^ there are long-established sites on the internet with mail archives that go back decades, archives with messages containing these elements. While these archives may only be mined occasionally, they are nonetheless still in use, making "obsolete" the incorrect term to describe these elements. and add something like:    Another, similar, reason for this requirement is that many people have    decades-old messages in their personal message stores, and for various    reasons it is occasionally useful to not only read such messages but    also resend or forward them to others. Later efforts to revise this specification contemplated changing the term to "legacy" or something that would more accurately describe the elements,  but such a change was rejected due tofears that it would result in  unnecessary confusion, especially amonglong-time users and implementers of  the specification. --------------12A5D1D9DA3D60F1D71BEA9A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 5/6/21 10:21 PM, Todd Herr wrote:

   Note: The dictionary definition of "obsolete" is "no longer in use or 

   no longer useful". While this specification mandates that these syntactic

   elements no longer be generated, it also mandates that conformant parsers 

   be able to support them. The reason for this latter requirement is that  

   there are long-established sites on the internet with mail archives that 

   go back decades, archives with messages containing these elements. While 

   these archives may only be mined occasionally, they are nonetheless still 

   in use, making "obsolete" the incorrect term to describe these elements. 

   Later efforts to revise this specification contemplated changing the term 

   to "legacy" or something that would more accurately describe the elements, 

   but such a change was rejected due to fears that it would result in 

   unnecessary confusion, especially among long-time users and implementers of 

   the specification.


Suggest instead:

   Note: The dictionary definition of "obsolete" is "no longer in use or 

   no longer useful". While this specification mandates that these syntactic

   elements no longer be generated, it also mandates that conformant parsers 

   be able to support them. One reason for this latter requirement is that 

                            ^^^

   there are long-established sites on the internet with mail archives that 

   go back decades, archives with messages containing these elements. While 

   these archives may only be mined occasionally, they are nonetheless still 

   in use, making "obsolete" the incorrect term to describe these elements.

and add something like:


   Another, similar, reason for this requirement is that many people have
   decades-old messages in their personal message stores, and for various
   reasons it is occasionally useful to not only read such messages but
   also resend or forward them to others.

   Later efforts to revise this specification contemplated changing the term 

   to "legacy" or something that would more accurately describe the elements, 

   but such a change was rejected due to fears that it would result in 

   unnecessary confusion, especially among long-time users and implementers of 

   the specification.

--------------12A5D1D9DA3D60F1D71BEA9A-- From nobody Thu May 6 21:54:53 2021 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 3DFDF3A17E2; Thu, 6 May 2021 21:54:51 -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 vwQLbmUFnmar; Thu, 6 May 2021 21:54:43 -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 C26D93A17E1; Thu, 6 May 2021 21:54:43 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lesVe-000FyU-2l; Fri, 07 May 2021 00:54:42 -0400 Date: Fri, 07 May 2021 00:54:37 -0400 From: John C Klensin To: Todd Herr , emailcore@ietf.org Message-ID: In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.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] 'obsolete' considered misleading 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: Fri, 07 May 2021 04:54:51 -0000 --On Thursday, May 6, 2021 22:21 -0400 Todd Herr wrote: > As chair... > > It seems we were close to consensus earlier this week on the > idea of adding some text to section 1.2.3 explaining that > "obsolete" wasn't really the correct word to use, with a back > reference to it in section 4, but now the thread has wandered > off that path. I'm going to try to bring it back to the path, > because I think the thread has run its course, and I'd like to > bring this to a conclusion and move on. > > Let me propose some text to see if we can't nudge this across > the line. > > Here is the current paragraph from section 1.2.3: > > Section 4 of this document specifies an "obsolete" syntax. > There are > references in section 3 to these obsolete syntactic > elements. The >... > And I propose as a starting point adding the following > paragraph after that one: > Note: The dictionary definition of "obsolete" is "no longer > in use or no longer useful". While this specification > mandates that these syntactic elements no longer be > generated, it also mandates that conformant parsers be able > to support them. The reason for this latter requirement is > that there are long-established sites on the internet with > mail archives that go back decades, archives with messages > containing these elements. While these archives may only be > mined occasionally, they are nonetheless still in use, > making "obsolete" the incorrect term to describe these > elements. > Later efforts to revise this specification contemplated > changing the term to "legacy" or something that would more > accurately describe the elements, but such a change was > rejected due to fears that it would result in unnecessary > confusion, especially among long-time users and implementers > of the specification. > Have at it... Todd, I am ok with your text and wish we could accept it and move on. However, if we are trying to be absolutely correct, Keith is correct: some of the personal collections and archives are as important (at least to them and potential historians) as the more public or formally maintained ones that your text refers to. His text doesn't quite spell it out, but there is no reason why some of those collections have to be online ("one the internet" (sic)) either. If we want to recognize that, a much shorter and possibly more effective fix would be to change... Old: The reason for this latter requirement is that there are long-established sites... Proposed: Reasons for this latter requirement include the existence of both decades-old personal and organizational archives and long-established sites... Noting the possibility that we could now generate another long thread of messages in group editing and nit-picking of text, my suggestion is that Pete confirm that he understands and accepts the gist of the requested change and that we turn the finer details over to editor's discretion and, in the long run, whatever can be worked out with the RFC Editor. thanks, john From nobody Fri May 7 00:14:26 2021 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 7C4213A0CAF for ; Fri, 7 May 2021 00:14:24 -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=unavailable 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 0xkG2f3Is2II for ; Fri, 7 May 2021 00:14:19 -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 DEC9C3A0CAC for ; Fri, 7 May 2021 00:14:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYQ75NBZDC00HMSQ@mauve.mrochek.com> for emailcore@ietf.org; Thu, 6 May 2021 20:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620357187; bh=gvSO/L9kjoxB1noh4y7M43XSLjKPLtU7dFpOYdBrl2Q=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=rmcgojt8/W5hoGhINgHa5WjTxKKHrOscoYeX5FBGJGD3bouhMDXzaCu8NCX6g/SfP iDnFJIYguQNyAwHDo+gMjCPoApNWEO00OV9PG5DlH7kX7vpGzhieCNr8Fu5WGPEkdR kw2Sl45fh9BoGb1Xgz5xcyKvphwSnfP4B1lLF9Vw= 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 <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Thu, 6 May 2021 20:13:05 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RYQ75M2UP20085YQ@mauve.mrochek.com> Date: Thu, 06 May 2021 20:12:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 May 2021 22:21:40 -0400" References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> To: Todd Herr Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 07:14:25 -0000 Seems fine to me. Ned > As chair... > It seems we were close to consensus earlier this week on the idea of adding > some text to section 1.2.3 explaining that "obsolete" wasn't really the > correct word to use, with a back reference to it in section 4, but now the > thread has wandered off that path. I'm going to try to bring it back to the > path, because I think the thread has run its course, and I'd like to bring > this to a conclusion and move on. > Let me propose some text to see if we can't nudge this across the line. > Here is the current paragraph from section 1.2.3: > Section 4 of this document specifies an "obsolete" syntax. There are > references in section 3 to these obsolete syntactic elements. The > rules of the obsolete syntax are elements that have appeared in > earlier versions of this specification or have previously been widely > used in Internet messages. As such, these elements MUST be > interpreted by parsers of messages in order to be conformant to this > specification. However, since items in this syntax have been > determined to be non-interoperable or to cause significant problems > for recipients of messages, they MUST NOT be generated by creators of > conformant messages. > And I propose as a starting point adding the following paragraph after that > one: > Note: The dictionary definition of "obsolete" is "no longer in use or > no longer useful". While this specification mandates that these syntactic > elements no longer be generated, it also mandates that conformant parsers > be able to support them. The reason for this latter requirement is that > there are long-established sites on the internet with mail archives that > go back decades, archives with messages containing these elements. While > these archives may only be mined occasionally, they are nonetheless still > in use, making "obsolete" the incorrect term to describe these elements. > Later efforts to revise this specification contemplated changing the term > to "legacy" or something that would more accurately describe the > elements, > but such a change was rejected due to fears that it would result in > unnecessary confusion, especially among long-time users and implementers > of > the specification. > Have at it... > -- > *Todd Herr* | Sr. Technical Program Manager > *e:* todd.herr@valimail.com > *m:* 703.220.4153 > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. From nobody Fri May 7 04:21:01 2021 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 4EF7B3A1C55 for ; Fri, 7 May 2021 04:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MT1u6j4YkyAL for ; Fri, 7 May 2021 04:20:54 -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 6EF953A1C58 for ; Fri, 7 May 2021 04:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1620386447; bh=2ocxOMUeGN1AoDGA2gJ/5Ao0w/gK01TkQa+WUYKtelA=; l=224; h=To:References:From:Date:In-Reply-To; b=CJbg7exg7jtpVHBBwU6GsyQ5epyTKdNbWsfk6oT/EKUAS9qbLevaO0njGLGyagQTN cDDhH5H9qATECSAflDITlGEeGmCizKPuEuO1EzpzqfUDkFVNtZdStN3xucIhLQpK6r flG6Eb4t56G+ieA5JQI9/Fzz9gp122TxblBz4r05saIGNERZrzO2Lm/KgcEvj Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.000000006095228F.000027CC; Fri, 07 May 2021 13:20:47 +0200 To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <9ce5eb1a-1e6b-2feb-4ada-7a0757dd919b@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Fri, 7 May 2021 13:20:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <9ce5eb1a-1e6b-2feb-4ada-7a0757dd919b@dcrocker.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 11:20:59 -0000 On Fri 07/May/2021 04:25:53 +0200 Dave Crocker wrote: > On 5/6/2021 7:21 PM, Todd Herr wrote: >> Have at it... > > Your proposed text is quite good. +1, since the map and the terrain disagree... Best Ale -- From nobody Fri May 7 04:37:47 2021 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 C3ACC3A1C69 for ; Fri, 7 May 2021 04:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 EX9ehipXsTU8 for ; Fri, 7 May 2021 04:37:41 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB863A1CF5 for ; Fri, 7 May 2021 04:37:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9E4C811E8 for ; Fri, 7 May 2021 07:37:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 07 May 2021 07:37:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=naBxEyoKEbYh4dG4Zbr7QrnhiI1wMs63E9Hk/eqfI bM=; b=LXEUzH1SqDWmDkRES7Uctc7q+ROHUw27erq/gV3z49rRCkxDsgnt6ToTG JVpvOhbjBYAgDGHNlmxhFhtLOredzp5wSoXb8OamOu++65e8Xa65jofcq2POhivB Z4ZCKJWFwR/8kEjLOV0V1JWK/1GqCcRr/8jWmnZwdLaQaBb0JaUt+vgEsnpuEN1f 3Wk/r8u2X1priVrlZEqIfI3uSe9ybAK8nIQ6sRNYGkPtAzau+MXYeZ1LFwJj2vlx 4VvpHsPWqrJnVNye41XL7zJUIlaB/eT3AY2pBDLOh2IFcLw6V9Kxh0tFB9XMyUx2 27Oa8DyespzmZyVJtvDcn6oG8muzA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegvddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtje ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeekvdeggfelue elkeeuhfffheeghffhkeeuvdduudeihfehudefffdtgfdtkeffgfenucfkphepvdefrddu vdegrddutddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.121] (23-124-10-170.lightspeed.knvltn.sbcglobal.net [23.124.10.170]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 7 May 2021 07:37:38 -0400 (EDT) To: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> From: Keith Moore Message-ID: Date: Fri, 7 May 2021 07:37:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 11:37:46 -0000 On 5/7/21 12:54 AM, John C Klensin wrote: > Noting the possibility that we could now generate another long > thread of messages in group editing and nit-picking of text, my > suggestion is that Pete confirm that he understands and accepts > the gist of the requested change and that we turn the finer > details over to editor's discretion and, in the long run, > whatever can be worked out with the RFC Editor. > I'd be ok with this. Keith From nobody Fri May 7 08:30:04 2021 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 A4C8A3A265E for ; Fri, 7 May 2021 08:30:01 -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 R3y611PPTE34 for ; Fri, 7 May 2021 08:29:57 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F97D3A2658 for ; Fri, 7 May 2021 08:29:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id F177CE4D5A63; Fri, 7 May 2021 10:29:55 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzB3lCVif_yB; Fri, 7 May 2021 10:29:55 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 1FA50E4D5A5C; Fri, 7 May 2021 10:29:55 -0500 (CDT) From: Pete Resnick To: Keith Moore Cc: emailcore@ietf.org Date: Fri, 07 May 2021 10:29:53 -0500 X-Mailer: MailMate (1.14r5800) Message-ID: <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 15:30:02 -0000 On 7 May 2021, at 6:37, Keith Moore wrote: > On 5/7/21 12:54 AM, John C Klensin wrote: > >> Noting the possibility that we could now generate another long >> thread of messages in group editing and nit-picking of text, my >> suggestion is that Pete confirm that he understands and accepts >> the gist of the requested change and that we turn the finer >> details over to editor's discretion and, in the long run, >> whatever can be worked out with the RFC Editor. >> > I'd be ok with this. I do believe I understand the gist, and I'm happy to take the text here and wordsmith it as appropriate. I'll look to put something both in 1.2.3 and at least a back pointer at the top of section 4. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri May 7 08:42:06 2021 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 741FE3A26D4 for ; Fri, 7 May 2021 08:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (2048-bit key) header.d=valimail.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 5oBL3wxG6XLW for ; Fri, 7 May 2021 08:41:59 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 5AA673A26D7 for ; Fri, 7 May 2021 08:41:32 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id a18so6876423qtj.10 for ; Fri, 07 May 2021 08:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6VLwU1mxgdAEZTX5mgAWeDeVfVkGWmiVy1icaPBRMJQ=; b=XAIKuQThnQNsxNEWzXGqm8WnMhcomQoDiqWmvwPFoN4ZnbvS8ym0WdflesbTAtZuEN cXEALred0SxzOGhrRAM5VLuU6pr6bjxZSZJBZ5Ks9UhkPzmmWd3+2h9VIOD4d+egLZp1 7oXYaaupD3ysjd7LQqLmfnCob4sJEgLUHpUc99JIFM1rbJnzjSTAZYosyrJcA5BMojF6 WAcsWTNM6E4O+ZMIvRlwgwg4Gx/q/BRIBWvZxm2gvFj9hJIYg76jFJLQExlWmzLl3X4k 24VoyTGK+5dIosc7IRccQ2z2LX5tF3GSy1StIB63COey4EqqkegdJCYa2y5eTjnY+skR H6uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6VLwU1mxgdAEZTX5mgAWeDeVfVkGWmiVy1icaPBRMJQ=; b=R8/FQ7N9bAegVtZUipPMt0dUGNgl/z8VtzlgXuDh0VJNyQWD/Y9YOPsCbEbLmtSVSt zHYQubYDZnRyJU28gxA3oz0pZemI6JBnjTM6dC9CsftsnJU0b6rLnJIocETmEk1tIXny QOnrTewGUwXc95APDTIHCOzM/EBtfuM7k2qItcKDcDFxTKKUulvXV+Mr0gZff8ItwFKh v8GAfdo/DkV9ZvzNBpfc5q3zz1rcnhR9NT31t1dy64+AXzlt5SaM58GvfjfZfcdDyuN4 iSxU1C8rMankGi6amb0/o82H8nEC4GuLE3f17fC5ShDhKKQ8PsOjvOLSad3zstyH5mlU K4hg== X-Gm-Message-State: AOAM5320Jk6GzmOmNCgfrD6p+gF65K0GfQz3TRiamRCXiSlI0qCZPniF 2kBMZH3m4pFCx1bxHyYrVzQnzTCu6gbZD7rDSDuCIOf/+sY= X-Google-Smtp-Source: ABdhPJzMbwFOrHsV3lBnp2VAlgZovbpmtnQz3t+rY0VUwd33RcWcWWtULBHYdX3fLSeSr32yqI9l+1owtAI3TypND6I= X-Received: by 2002:ac8:754a:: with SMTP id b10mr10164180qtr.83.1620402090293; Fri, 07 May 2021 08:41:30 -0700 (PDT) MIME-Version: 1.0 References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> In-Reply-To: <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> From: Todd Herr Date: Fri, 7 May 2021 11:41:14 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc4acb05c1bf4219" Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 15:42:05 -0000 --000000000000fc4acb05c1bf4219 Content-Type: text/plain; charset="UTF-8" On Fri, May 7, 2021 at 11:30 AM Pete Resnick wrote: > On 7 May 2021, at 6:37, Keith Moore wrote: > > > On 5/7/21 12:54 AM, John C Klensin wrote: > > > >> Noting the possibility that we could now generate another long > >> thread of messages in group editing and nit-picking of text, my > >> suggestion is that Pete confirm that he understands and accepts > >> the gist of the requested change and that we turn the finer > >> details over to editor's discretion and, in the long run, > >> whatever can be worked out with the RFC Editor. > >> > > I'd be ok with this. > > I do believe I understand the gist, and I'm happy to take the text here > and wordsmith it as appropriate. I'll look to put something both in > 1.2.3 and at least a back pointer at the top of section 4. > > Thanks, Pete (and everyone who contributed). Let's call this thread closed and move on to other matters. As chair... -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000fc4acb05c1bf4219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 7, 2021 at 11:30 AM Pete Resnick <resnick@episteme.net> wrote:
<= /div>
On 7 May 2021, at 6:37, Keith Moore wrote:

> On 5/7/21 12:54 AM, John C Klensin wrote:
>
>> Noting the possibility that we could now generate another long
>> thread of messages in group editing and nit-picking of text, my >> suggestion is that Pete confirm that he understands and accepts >> the gist of the requested change and that we turn the finer
>> details over to editor's discretion and, in the long run,
>> whatever can be worked out with the RFC Editor.
>>
> I'd be ok with this.

I do believe I understand the gist, and I'm happy to take the text here=
and wordsmith it as appropriate. I'll look to put something both in 1.2.3 and at least a back pointer at the top of section 4.


Thanks, Pete (and everyone who contributed).

<= /div>
L= et's call this thread closed and move on to other matters.

As chair.= ..
--

=
Todd Herr<= span style=3D"vertical-align:baseline;white-space:pre-wrap;font-size:small;= font-family:Arial"> | Sr. Technical Program Manager
m: 703.220.4153

This email and all data transmitted with it contains confid= ential and/or proprietary information intended solely for the use of indivi= dual(s) authorized to receive it. If you are not an intended and authorized= recipient you are hereby notified of any use, disclosure, copying or distr= ibution of the information included in this transmission is prohibited and = may be unlawful. Please immediately notify the sender by replying to this e= mail and then delete it from your system.

--000000000000fc4acb05c1bf4219-- From nobody Fri May 7 08:42:55 2021 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 892883A26EA for ; Fri, 7 May 2021 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (2048-bit key) header.d=dcrocker.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 774QcTYZB8g8 for ; Fri, 7 May 2021 08:42:48 -0700 (PDT) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 075B33A26E4 for ; Fri, 7 May 2021 08:42:47 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A53F8681F98; Fri, 7 May 2021 15:42:45 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-133-96.trex.outbound.svc.cluster.local [100.96.133.96]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id E8860681E74; Fri, 7 May 2021 15:42:43 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.133.96 (trex/6.2.1); Fri, 07 May 2021 15:42:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Belong-Trail: 44403b2074738264_1620402164972_3730320413 X-MC-Loop-Signature: 1620402164972:4111446189 X-MC-Ingress-Time: 1620402164972 Received: from [192.168.0.111] (c-24-130-56-204.hsd1.ca.comcast.net [24.130.56.204]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id C08632061AD0; Fri, 7 May 2021 15:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1620402162; bh=CNcVhm+5VaiUKN2Q20asv8n+Uu9wOY2Oq554BhLnjcY=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=XDqf/GRuiwabND9qTU/lvn+7Xpfh82ttHgsx+tUnPB+ckyzmvpBGh8rNkCU8BeVNy Mff1B29iu4+pncNygCdxEnyPYVlolTEFJVysf4flwH9qi0ng1wyAdL6dcNvm7mFrH9 8IIGkbAnFhEH4VYmKdLMkfyZH+WsLcBtgfJdJAk88cqFP4NI+K1wqhCHxEJVBeCRB4 l5GYd7hnK7jS0x6poNpnJ7f+cWsSOmv4Yo1e60XKGlnM890U+mP1vB4jIJIieWLoQD nEF14kZOT6fEAnEExLlHQRKHx5UYdE9MZ/TZLOhXYAfrS3CwIE69Cwxc2JMX421AJ6 s2VYxKWJGD9nA== Reply-To: dcrocker@bbiw.net To: Pete Resnick Cc: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> Date: Fri, 7 May 2021 08:42:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 15:42:54 -0000 On 5/7/2021 8:29 AM, Pete Resnick wrote: > I do believe I understand the gist, and I'm happy to take the text here > and wordsmith it as appropriate. I'll look to put something both in > 1.2.3 and at least a back pointer at the top of section 4. Now I'm confused. Todd offered precise language. Ned, Alessandro and I express solid support for that language. John says he is ok with the text but then proceeds to explain that he really isn't. Keith expresses a desire for you to do separate wordsmithing. That is 4 people (but arguably 5) like an existing set of words. Two others suggest a task that has only generic parameters, with no clear sense of deficiencies in the existing, proposed text. And the conclusion is that you should do separate wordsmithing? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 7 09:16:25 2021 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 4A1733A26DB for ; Fri, 7 May 2021 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (2048-bit key) header.d=valimail.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 gg9UFYdhXmCA for ; Fri, 7 May 2021 09:16:19 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 2CFD83A274B for ; Fri, 7 May 2021 09:16:19 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id i67so8978839qkc.4 for ; Fri, 07 May 2021 09:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1bcEZ6q1uUFepBLcFRNGsIzoiyyzl71CgxpArOjQxVo=; b=TzHZUZhYU18YFP0n+y66vgUIAkbGeyV/Ga6s/yL9IR6TPD5Ubj22oyOCIHq/HgMf4m bWwFIEy7s4RtuRnI8qI/TfqCr4zPTDXx6ICtNDezrgxGVpTWtMmAkwg2nagcg8sEUj8I ROMaawRHHXVCSsLkiOp6bvt9W8eRWuv5XfvHOsiUuMwNki3GzOTn3demcDNpLANWQs6J yMBl5xwwtNXCMTGVvIMVqbDwaqbh8hyzYF9MgEXA6KbbqHe2YaM5T0DCLMzV4EZuBw0d PipOyt55y+onAn1rdZ1zJs6SMlDHFS2DmMnaCEbhCwBGdO0fKMIR+2QMzXEB9q1qeY20 JwVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1bcEZ6q1uUFepBLcFRNGsIzoiyyzl71CgxpArOjQxVo=; b=qfUr8BUhMb1ERQtr/gP4h+LbucBnDVSPr4ZgmFsFaq2a/3g8O0ef/MKyWlrHBTDLLO Nizo3C0GFcS40ahk3G04Ot2I9OZtsYwNOyd2muAILCP6pYklNTUHzPolIzATZ7Bu9Klo lwwBKpZy48T8MwbGrG3Qf7A60aSqDG1rnrn4CtUyEQkpRbB31hIJme3PXC5+aAgfGsjp U0zCwMrUXc+QANBIwXhk6rt74ImojZyf8w/nAzeOFhwKDYoDdrouMpZAbGetxxZ9p+uH BmZTZgIXsNs3vNC/X1AV87QpbnpAqoUzlE7rp2BOjSX9B5CCL3aBTelXAO6NyvUzTDlA BSPQ== X-Gm-Message-State: AOAM532gZPFEXdvlTp0b3MJFDLFYAuleEzVInVGWHILBFxcW7ucGsiV6 43Xh5jlbQYO5Szb5+IckOJt1vcACq9P7hXk3T4voCLTne5jYrQ== X-Google-Smtp-Source: ABdhPJyS6bSK9txWuJB6dkbNM3MMUcC8FzbE6hIAE9Q9ZWWzoV9DdVuNXI2fXSUzvs6dwE3e2gKxCcr1kij7mVyUIBM= X-Received: by 2002:a37:a988:: with SMTP id s130mr10734900qke.325.1620404177047; Fri, 07 May 2021 09:16:17 -0700 (PDT) MIME-Version: 1.0 References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> In-Reply-To: <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> From: Todd Herr Date: Fri, 7 May 2021 12:16:01 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000005da8b905c1bfbf08" Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 16:16:24 -0000 --0000000000005da8b905c1bfbf08 Content-Type: text/plain; charset="UTF-8" On Fri, May 7, 2021 at 11:43 AM Dave Crocker wrote: > On 5/7/2021 8:29 AM, Pete Resnick wrote: > > I do believe I understand the gist, and I'm happy to take the text here > > and wordsmith it as appropriate. I'll look to put something both in > > 1.2.3 and at least a back pointer at the top of section 4. > > Now I'm confused. > > Todd offered precise language. Ned, Alessandro and I express solid > support for that language. > > John says he is ok with the text but then proceeds to explain that he > really isn't. > > Keith expresses a desire for you to do separate wordsmithing. > > That is 4 people (but arguably 5) like an existing set of words. > > Two others suggest a task that has only generic parameters, with no > clear sense of deficiencies in the existing, proposed text. > > And the conclusion is that you should do separate wordsmithing? > > > I believe the only wordsmithing or even substantive changes to the text I proposed was in regards to calling out two distinct types of old mail stores rather than the one that was in my original text. My text referred to "long-established sites on the internet with mail archives that go back decades" and may be mined, and Keith suggested adding "many people have decades-old messages in their personal message stores, and for various reasons it is occasionally useful to not only read such messages but also resend or forward them to others" as a second example of mail stores that contain mail messages that have obsolete syntax. There is consensus that "obsolete" is the wrong word to use, and there is consensus to add a paragraph explaining why it's wrong but won't be changed. There is language for this paragraph in the combination of what I wrote and what Keith added to what I wrote: Note: The dictionary definition of "obsolete" is "no longer in use or no longer useful". While this specification mandates that these syntactic elements no longer be generated, it also mandates that conformant parsers be able to support them. One reason for this latter requirement is that there are long-established sites on the internet with mail archives that go back decades, archives with messages containing these elements. While these archives may only be mined occasionally, they are nonetheless still in use, making "obsolete" the incorrect term to describe these elements. Another, similar, reason for this requirement is that many people have decades-old messages in their personal message stores, and for various reasons it is occasionally useful to not only read such messages but also resend or forward them to others. Later efforts to revise this specification contemplated changing the term to "legacy" or something that would more accurately describe the elements, but such a change was rejected due to fears that it would result in unnecessary confusion, especially among long-time users and implementers of the specification. I see nothing factually incorrect in that language, and I don't expect that any wordsmithing Pete might do will alter the message being conveyed here, which is "Obsolete is the wrong word, because reasons, but we didn't change it, because confusion." When the document gets to the RFC Editor part of the process, it could very well see a change made that combines the two examples (long-established sites that mine old messages and people who read old messages) into one more generic example, perhaps drawing on or similar to what John wrote ("Reasons for this latter requirement include the existence of both decades-old personal and organizational archives and long-established sites... ") or perhaps Pete will make such a change himself, but again, that won't change the overall message of "Obsolete wrong word because reasons, didn't change because confusion." -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000005da8b905c1bfbf08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, May 7, 2021 at 11:43 AM Dave Croc= ker <dhc@dcrocker.net> wrote:=
On 5/7/2021 8:2= 9 AM, Pete Resnick wrote:
> I do believe I understand the gist, and I'm happy to take the text= here
> and wordsmith it as appropriate. I'll look to put something both i= n
> 1.2.3 and at least a back pointer at the top of section 4.

Now I'm confused.

Todd offered precise language.=C2=A0 Ned, Alessandro and I express solid support for that language.

John says he is ok with the text but then proceeds to explain that he
really isn't.

Keith expresses a desire for you to do separate wordsmithing.

That is 4 people (but arguably 5) like an existing set of words.

Two others suggest a task that has only generic parameters, with no
clear sense of deficiencies in the existing, proposed text.

And the conclusion is that you should do separate wordsmithing?



I believe the only wordsmithing or even = substantive changes to the text I proposed was in regards to calling out tw= o distinct types of old mail stores rather than the one that was in my orig= inal text.

My text referred to "long-est= ablished sites on the internet with mail archives that=C2=A0= go back decades" and may be mined, and Keith suggested adding "<= /span>many people have=C2=A0decades-old messages in their personal= message stores, and for various=C2=A0reasons it is occasionally us= eful to not only read such messages but=C2=A0also resend or forward= them to others" as a second example of mail stores that contain mail = messages that have obsolete syntax.

There= is consensus that "obsolete" is the wrong word to use, and there= is consensus to add a paragraph explaining why it's wrong but won'= t be changed. There is language for this paragraph in the combination of wh= at I wrote and what Keith added to what I wrote:

=C2=A0=C2=A0=C2=A0Note: The dictionary definition of = "obsolete" is "no longer in use or=C2=A0

=C2=A0=C2= =A0=C2=A0no longer useful". While this specification mandates that the= se syntactic

=C2=A0=C2=A0=C2=A0elements no longer be generated, it = also mandates that conformant parsers=C2=A0

= =C2=A0=C2=A0=C2= =A0be able to support them. One reason for this latter requirement is that= =C2=A0

=C2=A0=C2=A0=C2=A0there are long-es= tablished sites on the internet with mail archives that=C2=A0

=C2=A0=C2=A0=C2=A0go back decades, archives with messages con= taining these elements. While=C2=A0

=C2=A0=C2=A0=C2=A0these archive= s may only be mined occasionally, they are nonetheless still=C2=A0

= =C2=A0=C2=A0=C2=A0in use, making "obsolete" the incorrect term to= describe these elements.


=C2=A0=C2=A0 A= nother, similar, reason for this requirement is that many people have
= =C2=A0=C2=A0 decades-old messages in their personal message stores, and for= various
=C2=A0=C2=A0 reasons it is occasionally useful to not only read= such messages but
=C2=A0=C2=A0 also resend or forward them to others.

=C2=A0= =C2=A0=C2=A0Later efforts to revise this specification contemplated changin= g the term=C2=A0

=C2=A0=C2=A0=C2=A0to "legacy" or somethi= ng that would more accurately describe the elements,=C2=A0

=C2=A0 = =C2=A0but such a change was rejected due to=C2=A0fears that it would result in=C2=A0=

=C2=A0 =C2=A0unnecessary confusion, especially among=C2=A0long-time users and implem= enters of=C2=A0

=C2=A0 =C2=A0the specification.


I see nothing factually incorrect in that = language, and I don't expect that any wordsmithing Pete might do will a= lter the message being conveyed here, which is "Obsolete is the wrong = word, because reasons, but we didn't change it, because confusion."= ;=C2=A0

When the document gets= to the RFC Editor part of the process, it could very well see a change mad= e that combines the two examples (long-established sites that mine old mess= ages and people who read old messages) into one more generic example, perha= ps drawing on or similar to what John wrote ("Reasons fo= r this latter requirement include the existence of both decades-old persona= l and organizational archives and long-established sites... ")=C2=A0or perhaps Pete will make such a change h= imself, but again, that won't change the overall message of "Obsol= ete wrong word because reasons, didn't change because confusion."<= /span>



--

= Todd Herr | Sr. Technical Program Manager=
m: 703.220.4153

This email and all data transmitted= with it contains confidential and/or proprietary information intended sole= ly for the use of individual(s) authorized to receive it. If you are not an= intended and authorized recipient you are hereby notified of any use, disc= losure, copying or distribution of the information included in this transmi= ssion is prohibited and may be unlawful. Please immediately notify the send= er by replying to this email and then delete it from your system.

--0000000000005da8b905c1bfbf08-- From nobody Fri May 7 10:37:05 2021 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 1C65B3A2B75 for ; Fri, 7 May 2021 10:37:03 -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 D2fsn_-oqWUB for ; Fri, 7 May 2021 10:36:58 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6AF3A2B72 for ; Fri, 7 May 2021 10:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 24DBEE4DA70E; Fri, 7 May 2021 12:36:57 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClTOEgJWipmw; Fri, 7 May 2021 12:36:30 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 42EE2E4DA635; Fri, 7 May 2021 12:36:17 -0500 (CDT) From: Pete Resnick To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Fri, 07 May 2021 12:36:15 -0500 X-Mailer: MailMate (1.14r5800) Message-ID: <6C865BBF-3F19-4D71-9040-4EF142F54F1F@episteme.net> In-Reply-To: <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 17:37:03 -0000 On 7 May 2021, at 10:42, Dave Crocker wrote: > On 5/7/2021 8:29 AM, Pete Resnick wrote: >> I do believe I understand the gist, and I'm happy to take the text >> here and wordsmith it as appropriate. I'll look to put something both >> in 1.2.3 and at least a back pointer at the top of section 4. > > Now I'm confused. I hope Todd's followup message helped to unconfuse you, as I think it's exactly right. To be clearer about what I meant: > Todd offered precise language. Ned, Alessandro and I express solid > support for that language. Yep. Got that part. > John says... Actually Keith first says that he's OK with the text, but wants a clarification that mail archives are not the one and only reason for parsing these "obs-" forms, and suggested some language. > John says he is ok with the text but then proceeds to explain that he > really isn't. I don't think that's true. John says he agrees with Keith's addition and gives some slightly different proposed wording for that addition. He then suggests that I simply have a go at integrating the addition, which, as Todd says, doesn't disagree with anything he wrote. > Keith expresses a desire for you to do separate wordsmithing. I would rephrase to say, Keith expresses agreement that I integrate the additional text. > That is 4 people (but arguably 5) like an existing set of words. Yep, I like them too. And save the word "the", and adding an additional example, two others seem to like them too. > Two others suggest a task that has only generic parameters, with no > clear sense of deficiencies in the existing, proposed text. They did give a clear description of the deficiency (identifying archives as the only reason), and provided text to clarify. > And the conclusion is that you should do separate wordsmithing? My conclusion was that integrating Keith and/or John's examples was something I was able to figure out without substantively changing anything Todd wrote and that I was willing to do that. I hope that makes my intent clear. There's no action you asked me to take or not take in your message, so I will go forward with my plan unless you or others say otherwise. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri May 7 10:40:22 2021 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 67CC73A2BE2 for ; Fri, 7 May 2021 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (2048-bit key) header.d=dcrocker.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 PPZO2NPPwz7H for ; Fri, 7 May 2021 10:40:09 -0700 (PDT) Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) (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 742643A2BA0 for ; Fri, 7 May 2021 10:39:50 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 65111681148; Fri, 7 May 2021 17:39:48 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-18-74.trex.outbound.svc.cluster.local [100.96.18.74]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 5B598680C25; Fri, 7 May 2021 17:39:46 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.18.74 (trex/6.2.1); Fri, 07 May 2021 17:39:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Sponge-Rock: 786015094bf9ea34_1620409188084_2839592931 X-MC-Loop-Signature: 1620409188084:4216534778 X-MC-Ingress-Time: 1620409188084 Received: from [192.168.0.111] (c-24-130-56-204.hsd1.ca.comcast.net [24.130.56.204]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 0DF6331EACA9; Fri, 7 May 2021 17:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1620409184; bh=yFrGAObCV7cveTqFeBvgNpUG+qnOIt4zFTuWs/jZpBo=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZyZneRSHJIt6diL15GNZNOA2jv7aBDQCRwY6sdAaCy2sgV3Mu036HTGgQFJBcnQXH fZkDgN1igzCUJDVIA+VXK30nrOUT8efI2HU/4U5dqZp6KTdLi2COageLzHJiwl3/e+ 1e77A6EZT4Znri0q9yQHhK1az85MjLV0NuFGnPY5AIkFAiXFVrHaRAHrNl12ooJYUQ WPC7+XzMRNUEQyUK0/7OLWwuUnSwBjwzwHpSrBj6YuIKSsb5fkb9AX6svEutdHR1lc v3OJLda6fOmtSlaLABku98uI0QXrUtc+g7T94E7uF+23/Os6Pe12dJhsozQLlK8TIg lVaLCKx3nDVig== Reply-To: dcrocker@bbiw.net To: Pete Resnick , dcrocker@bbiw.net Cc: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> <743FB085-E19B-4F20-8AB1-A2219441FC06@episteme.net> <4db2c7c8-396a-3832-7e4e-3551afe896f9@dcrocker.net> <6C865BBF-3F19-4D71-9040-4EF142F54F1F@episteme.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7294b57d-aad4-5d93-6214-a454318e4528@dcrocker.net> Date: Fri, 7 May 2021 10:39:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <6C865BBF-3F19-4D71-9040-4EF142F54F1F@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 17:40:20 -0000 On 5/7/2021 10:36 AM, Pete Resnick wrote: > > I hope Todd's followup message helped to unconfuse you, sure. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 7 12:14:25 2021 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 DF0863A2EF3 for ; Fri, 7 May 2021 12:14:23 -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 lIl0nu35JYfV for ; Fri, 7 May 2021 12:14:19 -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 70A6D3A2F13 for ; Fri, 7 May 2021 12:14:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYQWEPF1MO00GFNN@mauve.mrochek.com> for emailcore@ietf.org; Fri, 7 May 2021 08:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620400551; bh=xSXqAP5LduZHhGRJVR65cCaT9GhDRRTsbVpHBIybybk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=eg9YUC1k+NE6OUMhmt2vx/cHCmoV0RQHYE7oRpmazeZanqTSpXpx/4REbSC7227jc JFuDWG0Mxu+JV/tImkMCQpLAom1g/36EQRcLyD8OqmYn0+lCVUYFx/AQMthszsj4Gc oXvhwfAvYqDZ1ciebiFqi0/EL1vegMXbvEwS+xrc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYQWDYJK4G0085YQ@mauve.mrochek.com>; Fri, 7 May 2021 08:15:48 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RYQWEMVQMG0085YQ@mauve.mrochek.com> Date: Fri, 07 May 2021 08:15:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 07 May 2021 07:37:37 -0400" References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> <01RYDDYSYKQ60085YQ@mauve.mrochek.com> <5CE15574-94F9-421C-8950-D799CC9214DB@episteme.net> <89303ddf-6ea7-a51a-c30c-d2fff4ae9f9f@dcrocker.net> <4821e294-1abb-db34-fcdc-cb14d5d6f1b4@network-heretics.com> <64712d85-1c0c-c19b-d9dc-9fe0d6b63fee@tana.it> <01RYO4Z5MQQI0085YQ@mauve.mrochek.com> <0f7b85ab-53ab-d9f0-9c30-33ecb07de160@tana.it> <01RYOD6255T80085YQ@mauve.mrochek.com> To: Keith Moore Archived-At: Subject: Re: [Emailcore] 'obsolete' considered misleading 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: Fri, 07 May 2021 19:14:24 -0000 > On 5/7/21 12:54 AM, John C Klensin wrote: > > Noting the possibility that we could now generate another long > > thread of messages in group editing and nit-picking of text, my > > suggestion is that Pete confirm that he understands and accepts > > the gist of the requested change and that we turn the finer > > details over to editor's discretion and, in the long run, > > whatever can be worked out with the RFC Editor. > > > I'd be ok with this. +1 Ned From nobody Tue May 11 02:24:04 2021 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 0ADCE3A03FE; Tue, 11 May 2021 02:24:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, emailcore-chairs@ietf.org, emailcore@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162072504140.6419.3796281808491696142@ietfa.amsl.com> Date: Tue, 11 May 2021 02:24:01 -0700 Archived-At: Subject: [Emailcore] emailcore - New Meeting Session Request for IETF 111 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: Tue, 11 May 2021 09:24:02 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the emailcore working group. --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: extra jmap dmarc uta Technology Overlap: calext dispatch secdispatch Key Participant Conflict: gendispatch wpack People who must be present: Pete Resnick Alexey Melnikov Murray Kucherawy Dr. John C. Klensin Todd Herr Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu May 13 17:44:24 2021 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 D45493A1AEB for ; Thu, 13 May 2021 17:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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 (2048-bit key) header.d=fastmailteam.com header.b=DOS/Ebm1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lXtAlPWB 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 CjjipyS3gCrd for ; Thu, 13 May 2021 17:44:16 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1A73A1AE9 for ; Thu, 13 May 2021 17:44:16 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 8190F3ED for ; Thu, 13 May 2021 20:44:14 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute2.internal (MEProxy); Thu, 13 May 2021 20:44:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=A8KghMet3rIYO0HqhfT92+KlWwWOMTU1y9CpMms l/cI=; b=DOS/Ebm1IFs9sdi6bALwdULcpMZGCWmiTmER51xTL4lNmHaQPyROOBE JkRgdsVTAEXsMd3ZWmIwPOLxdfqB30utGOzVG93m/tgRl2GMNIneZkUo3fERDRi6 J4DGqri3Khu+eGKFwdlFDcpdAjhrqP19mhadoGS44CsJk6FIhUHaRb7yh4XQ+1hX kzFEaAqNIKodib2uxazaHe24UAXWtIJ7JS2J2oCy32xrn5BBAr3K6R4anlKnXnZq oXxu4Oh0/TU+smQRww1fATnwb/qphUCDBI3PfumNXRzrTMTQ8lqmJaYtQmtEXBoV VoqLry5eN3lqP2/tojyHoCoIlF9rRng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=A8KghMet3rIYO0HqhfT92+KlWwWOM TU1y9CpMmsl/cI=; b=lXtAlPWBv5xvbjdtNriX7DqK+CoZd4AdKqN3fiXYc51Lt fu132jL5hCQ0CtuEGhOvuPdC6g5V7T2mgtdR8Uip3qOvXkUDtZCxix0MU+f9p4d6 FEqHGWsAutr7evTHh9KXjdJ21rDzBjbygAHSVBLyC0D4bXyJ9oEV09IsGwnu1aMg bdDxnBkI5xfHGBuK+YQL45XpiZ5VXZ1GyIcAFBZcob9BSTjW+i1yNy7TQaldMVmU v0Ev2jx3In9cLh8wiyyqVJH9y3ZF7zD6ZQCChmL0SIwBJyhPy5PZrS+DQ9Qk8PcS e9zwMtK6ufCKjle713wFEVhS8nXsd9UUdyVo9vvrg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehhedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 477C0310005F; Thu, 13 May 2021 20:44:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-679-gd95ae7bd09-fm-ubox-20210510.002-gd95ae7bd Mime-Version: 1.0 Message-Id: Date: Fri, 14 May 2021 10:43:42 +1000 From: "Bron Gondwana" To: emailcore@ietf.org Content-Type: multipart/alternative; boundary=f250b6b99c4144648fb94b552d3d673e Archived-At: Subject: [Emailcore] Bug-compatibility 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: Fri, 14 May 2021 00:44:22 -0000 --f250b6b99c4144648fb94b552d3d673e Content-Type: text/plain I ran into a great fun little issue the other day - I sent an email to a few people including an IETF expander (draft-ietf-calext-jscalendar.all@ietf.org). I'm on that expander, and the email I got back was truncated at the work ASAP from this line of my much longer email, which was quoted-printable encoded: > ACTION: discussion on list to confirm cases work, then clear AUTH48 ASAP= . I'm planning to change our QP encoder to not wrap if there's just one character left in the line, which will avoid this particular bug ever happening again. Guidance of this sort (don't include a dot on a line by itself in your email for maximum safety) would be useful! to others I suspect! (and yes, I will report this bug to the IETF tools team) Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --f250b6b99c4144648fb94b552d3d673e Content-Type: text/html
I ran into a great fun little issue the other day - I sent an email to a few people including an IETF expander (draft-ietf-calext-jscalendar.all@ietf.org).  I'm on that expander, and the email I got back was truncated at the work ASAP from this line of my much longer email, which was quoted-printable encoded:

ACTION: discussion on list to confirm cases work, then clear AUTH48 ASAP=
.

I'm planning to change our QP encoder to not wrap if there's just one character left in the line, which will avoid this particular bug ever happening again.  Guidance of this sort (don't include a dot on a line by itself in your email for maximum safety) would be useful! to others I suspect!

(and yes, I will report this bug to the IETF tools team)

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--f250b6b99c4144648fb94b552d3d673e-- From nobody Mon May 17 11:40:46 2021 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 3CB113A0945 for ; Mon, 17 May 2021 11:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 X_ZoBiIU1dJ0 for ; Mon, 17 May 2021 11:40:40 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 7C30A3A093C for ; Mon, 17 May 2021 11:40:40 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 190B3D2137 for ; Mon, 17 May 2021 14:40:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 17 May 2021 14:40:38 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <89BA6BA7-F730-4080-8F35-AD53ED94058A@dukhovni.org> References: To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [Emailcore] Bug-compatibility 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, 17 May 2021 18:40:45 -0000 > On May 13, 2021, at 8:43 PM, Bron Gondwana = wrote: >=20 > I ran into a great fun little issue the other day - I sent an email to = a few people including an IETF expander = (draft-ietf-calext-jscalendar.all@ietf.org). I'm on that expander, and = the email I got back was truncated at the work ASAP from this line of my = much longer email, which was quoted-printable encoded: >=20 >> ACTION: discussion on list to confirm cases work, then clear AUTH48 = ASAP=3D >> . >>=20 >=20 > I'm planning to change our QP encoder to not wrap if there's just one = character left in the line, which will avoid this particular bug ever = happening again. Guidance of this sort (don't include a dot on a line = by itself in your email for maximum safety) would be useful! to others I = suspect! >=20 > (and yes, I will report this bug to the IETF tools team) Somebody's forwarding messages via sendmail(1) without the "-i" = option... They need to fix that. It is not only dot on a line by itself that = breaks, but also all leading dots get stripped from all lines. --=20 Viktor.