From nobody Sun Apr 4 09:59: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 460823A10A6 for ; Sun, 4 Apr 2021 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cketti.de 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 EPzxFlb0zofe for ; Sun, 4 Apr 2021 09:59:26 -0700 (PDT) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161]) (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 39F633A10A4 for ; Sun, 4 Apr 2021 09:59:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617555558; cv=none; d=strato.com; s=strato-dkim-0002; b=tSxCTuMF+flveu9Gt0cAzIldYQw/YHNCNFQNMCOToG57vFc005fs9EaDfFMuIKI2xB HCS2qeFfcwL+OFJatAfirsWPJFRIZU7f39/2Ondf0UEuTvMyqvO28cEcbQDK/im8ubmb 2F7qCii6ZbWi0ihklxCQuyTjFcht5VFknvCzxicYCANE1sobIDN/8/ANH3FfB1oLyr5v x7OcAdzvMhH/B3ASnWbCEoo7eqoPtYZJvM7Kmp+BTmuQV92nXVLHBpkkFLK/Yk9HMryL tmENoEw4N9bckJgwRyQOipQi6ZguyrzUy/WIKtK8UMGETEUKXw0gButv1Gevm9JDFpqn 6AKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1617555558; s=strato-dkim-0002; d=strato.com; h=Date:Message-ID:Subject:From:To:Cc:Date:From:Subject:Sender; bh=5OHtzHRr/JZ9G04TTEesw68XPub4Og19egZmEfLMYgI=; b=HIYPTenzcmrzWOSd3kAckyvAz7AJ87MSp23X581lAXxSxtTivQu5FYDvgm2PLBvo+A n+wPuAJCHJtf7rhKTB2xF5C2FVQwGm8nRU9AE9i78PzssifYDzPxVnk2qYV1bRSND68t jO8Wy32b4YVAFBedBQwv42a4MtBYfAE345KvcHfvhnhpBBgdHJTFCGmUp4ETtya/ughb oulQQBXOjr/AqfR8YF+cKJtcIqW2zpaULJUkGD5ZymsRCLjOMZFjsqtM98GMYvcrwZ7C XJ2XkwvfS1bzttfLGCNkWcbhhLziWdMQ34HvfjYOMWiJBo+Bqsvu07HGP1Euu29qoG2u MnwA== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1617555558; s=strato-dkim-0002; d=cketti.de; h=Date:Message-ID:Subject:From:To:Cc:Date:From:Subject:Sender; bh=5OHtzHRr/JZ9G04TTEesw68XPub4Og19egZmEfLMYgI=; b=SN97CuMxq4je3uqZDWnY9oVjmSg2iBPYyPmL0oJDWpDepbFaLpy2lnySVClkJqxRZ4 9cWfCqzzfJll+nPoPkcEx6oEyhkqBU/zzuzz6exYQ4wYCBJ5ZLRBpOdhQJG1TZua/Rue 6BLUAWqDxDAnnEhWuPPZAuv1GtqC4UidXneQdhQ4UF5K9fDjHGf16mkZsN8jjQIcO4XF Hlh38C5zXJtntAw9c6mmFMBN7972iXWiKPs6i7bDHEqsPzJCtjgk8U0nDjuZSmTfKYQa Pt7JURvKGbQUinJ37tYrD39ry1mxtBT312iVLY6ECDJctxz6MUR+kHlPEoYIqAVwiTFf hQUQ== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oIudZGrZypc/JjmcLt+v0i5IgITqhml5/sYRrVEOR/W1cWVw0lrqz8=" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2454:481:ba00:b5fc:ee68:eda0:51e3] by smtp.strato.de (RZmta 47.23.1 AUTH) with ESMTPSA id U00d60x34GxIUkk (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 4 Apr 2021 18:59:18 +0200 (CEST) To: emailcore@ietf.org From: cketti Message-ID: <71c7f57d-2b8c-6d65-a8d4-c27ca9752e9b@cketti.de> Date: Sun, 4 Apr 2021 18:59:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Emailcore] Email address local-part equivalence 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: Sun, 04 Apr 2021 16:59:31 -0000 Hi. RFC 5321 and rfc5321bis-02 contain the following text: > For any purposes that require generating or comparing > Local-parts (e.g., to specific mailbox names), all quoted forms MUST > be treated as equivalent, and the sending system SHOULD transmit the > form that uses the minimum quoting possible. I'm unsure how to interpret this sentence. What exactly is a "quoted form"? Are the following three addresses considered equivalent? local@domain.example "local"@domain.example "\l\o\c\a\l"@domain.example Or do "quoted forms" require the use of a quoted string, i.e. only the last two examples need to be treated as equivalent? Cheers cketti From nobody Sun Apr 4 11:31:34 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 A69473A1456 for ; Sun, 4 Apr 2021 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=DZo+uu8G; dkim=pass (2048-bit key) header.d=taugh.com header.b=NhZPycLv 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 nMxwYXEDCaSM for ; Sun, 4 Apr 2021 11:31:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF643A1450 for ; Sun, 4 Apr 2021 11:31:26 -0700 (PDT) Received: (qmail 58380 invoked from network); 4 Apr 2021 18:31:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e40a.606a05fc.k2104; bh=ObJj/R9+Gt+rjr857Xm2CeVsk5LgDGZt1v5L8u/QuBA=; b=DZo+uu8GcfIOLCiZHZKUtp3Oa/sQtxQ6XiFEAM45xlOa3kxkivmSpqvlcp8euvqd0Xd1PjE7OumzoWZ3Jtf36Mv7rNTe+Y2j4B8zC3G3aJTZHsBDS3nEOamy2XHu6WlXyc642jyVmG4DYeoLTfCCwqyik0Y52x2M0ot8iSzqMRsEQQB8t2Lodnb+SIIAIeTCx67TRlmHVXdX2kAAC7BfAdthzR7KkdbQlxFPZs3nM/MckRbpXE2vez7Kzn3/Ounu8YUwcooCtSsyaJIzYYeUreEZkEXQ2XEPI/N7iyeV7Sz3qrQz3N3lJkXvQIhjKjc5bMkZmQot8woPj6HcM88UAQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e40a.606a05fc.k2104; bh=ObJj/R9+Gt+rjr857Xm2CeVsk5LgDGZt1v5L8u/QuBA=; b=NhZPycLvCvRTdJh+O3sC64MpmhQNZaTq0ov5oeDQqgfn/UkekicfZrGsyhIgmJ+aYtBGye/a/XD3wAnfSWuQylxgF22vttb12uMnsv2xhje8OexRoG7j3MI+yUuPNPZ/ZyXIQ74eRZtdtDKcyjCMdhIimNWbWbYpK/DGdLma+KR1I2uV5QWO9gN8ewUuAEEMcZe2FtTgozs88Rdu8cyYo4WuFxRTh9fOPOO4F95kaLEnOdrBio30SMYwVF2U5UGQQ1gV345Enw5GI2qbTeCVnOzzSP5kXYtCTagDGLxFBXWHhxwso3a5bac58AWrk6yWCU+vlvoOcmsHZQJhttqLBw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2021 18:31:24 -0000 Received: by ary.qy (Postfix, from userid 501) id E29AB71F97D0; Sun, 4 Apr 2021 14:31:23 -0400 (EDT) Date: 4 Apr 2021 14:31:23 -0400 Message-Id: <20210404183123.E29AB71F97D0@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ck@cketti.de In-Reply-To: <71c7f57d-2b8c-6d65-a8d4-c27ca9752e9b@cketti.de> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Email address local-part equivalence 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: Sun, 04 Apr 2021 18:31:33 -0000 It appears that cketti said: >RFC 5321 and rfc5321bis-02 contain the following text: > > > For any purposes that require generating or comparing > > Local-parts (e.g., to specific mailbox names), all quoted forms MUST > > be treated as equivalent, and the sending system SHOULD transmit the > > form that uses the minimum quoting possible. > >I'm unsure how to interpret this sentence. What exactly is a "quoted >form"? Are the following three addresses considered equivalent? > >local@domain.example >"local"@domain.example >"\l\o\c\a\l"@domain.example > >Or do "quoted forms" require the use of a quoted string, i.e. only the >last two examples need to be treated as equivalent? Good question. I am fairly sure the intention has always been that all three versions are equivalent, i.e., unneeded quoting is ignored. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Apr 4 14:12: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 5B4DC3A1A9D for ; Sun, 4 Apr 2021 14:12:07 -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 h-rxPgOMeEge for ; Sun, 4 Apr 2021 14:12:02 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 39CC13A1A72 for ; Sun, 4 Apr 2021 14:12:01 -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 43735701BED for ; Sun, 4 Apr 2021 21:12:01 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-105-161-106.trex.outbound.svc.cluster.local [100.105.161.106]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 82F6970122E for ; Sun, 4 Apr 2021 21:11:58 +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.105.161.106 (trex/6.1.1); Sun, 04 Apr 2021 21:12:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Battle-White: 545d96b01950a907_1617570721023_1806858523 X-MC-Loop-Signature: 1617570721023:863697100 X-MC-Ingress-Time: 1617570721023 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 24C983130402 for ; Sun, 4 Apr 2021 21:11:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1617570717; bh=SJ6MlZrjUXV4JGehtuczAuM7tMQ/z0WW8wk3sv9gTdg=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=Aj47nYpGcBcVV8+NCo5KMcrLb+nvFIXvT8pNJWq+x7EPuaVJGShltiVhd1UlEq7MC t/YVqeV6/fdsUVtPqfYeZwRdgkFOXOeavv8Z/Zei63j5FEZi9F7KxoBMhSoHzAUvP+ VipfF/Um5CVHOtICSaMxHniC9MLjrnxq7XT0fBwOSgLqRvo2mR+oSuhgaDklt32Y+r 9ydZz5Zji+UlWbQ83TnO6jAAI3BEyFj0vo4IeQM2C3aDb7VApLLR2Bz2csNGe9yF+C hmg0eKlIaG8q7R6uNev91fo7DXjvK0MuPZrz17iAAK/X5R37ju13gQKI/FkiK8ize4 Hu8cDTcC9wqlw== Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20210404183123.E29AB71F97D0@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 4 Apr 2021 14:11:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210404183123.E29AB71F97D0@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Email address local-part equivalence 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: Sun, 04 Apr 2021 21:12:07 -0000 >> RFC 5321 and rfc5321bis-02 contain the following text: >> >>> For any purposes that require generating or comparing >>> Local-parts (e.g., to specific mailbox names), all quoted forms MUST >>> be treated as equivalent, and the sending system SHOULD transmit the >>> form that uses the minimum quoting possible. >> >> I'm unsure how to interpret this sentence. What exactly is a "quoted >> form"? Are the following three addresses considered equivalent? >> >> local@domain.example >> "local"@domain.example >> "\l\o\c\a\l"@domain.example >> >> Or do "quoted forms" require the use of a quoted string, i.e. only the >> last two examples need to be treated as equivalent? > > Good question. I am fairly sure the intention has always been that all three > versions are equivalent, i.e., unneeded quoting is ignored. It occurs to me that current language is in a normative form, as if there were an alternative. This actually could be confusing, as well as getting into the problematic area of comparison, what with both Unicode complexity and SMTP's supposedly ignoring the local-part. It's worth considering... OLD: For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible. NEW: All quoted forms are equivalent and the sending system SHOULD transmit the form that uses the minimum quoting possible. It might also be worth adding some examples, such as the above, to make this concrete. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Apr 6 10:18:16 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 64D2D3A2984 for ; Tue, 6 Apr 2021 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkyKjLZl1YHR for ; Tue, 6 Apr 2021 10:18:11 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 89A9D3A2983 for ; Tue, 6 Apr 2021 10:18:11 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id h23so8189181vsj.8 for ; Tue, 06 Apr 2021 10:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5bbWH3KcANF7YMlop5lJima1rJqNjUYES4QqfkcDTMk=; b=M80YPJCKGtba0bw2I+SUe93mftgTARbbQ7KQe+qHIXOsisf/1novsQTcxUJXPp2E9g HwUZKI8JoAuJ/Jqae8SAjVlLaGVFarKFGsM6YKFQNt10DfDWfvHNrYlfncLQvHUGMkuU aQ+P3/JdcCYU3vXrbHT7xHvjT+Y9ybVvTRMxUBEyHLA675BafXiSLPSH92eTXPxO+eUy C3WYPQNxhAivHcy5UtCXT6aJaf9D0+NkfGL/ALcQeC/BVn/HKV1bzZ6ZaMWyNDb1LWeL THHAgHc33cJjh3BrKIzSCtKB6Ax4kjBUDT95OaBHsd5Oojm6ILLpL98X1BVm2XAVNL5V 8BFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5bbWH3KcANF7YMlop5lJima1rJqNjUYES4QqfkcDTMk=; b=btBE93FPRm2EaC0uX2TiOb/jubVB41brpsCM1Txo7bSCsQnrqT6wpGAsOJDk1mEgys RYy+qtU3I1UvNzf9EEKy5FvEc1SYiEmop6OEW6ZtWEw3g29SAbChpy7OO0Guo9mA3kud 2afFWhEc7ROMcZorkPhDo2k7oqYAavqnzxzofzfkCfNkOxryLFmhSWa9C/gDbV1X7kBN ziFdo+RAz5aLcTjgoSq0ku4FYe2imCm4Xo9XIZvx0O56ZtUKAV8ubgzM001XByN4rSvm V25Fq6eP0dLfDpsuZzusco1k5tFVjIc2QNwjFj0IMnkqhyIIP78R96JClYCOKUe/UMlI 2PEw== X-Gm-Message-State: AOAM533VWzawEwNrig3CipOMei8CeHQtKYs03EZAmMwpvzayIHB3NMv0 1my6Ju1PshpByBylM7AjF9/90XLQl3Fx/tyWoheY9IrP X-Google-Smtp-Source: ABdhPJz+CcwoUSnG3Cy6RUdqnXIjvJR2kKZnucf+KuWUN8dbHtGRJHenDbSUenHGuW7hE2/XqIYNCJS9t63ZVnfqb3Q= X-Received: by 2002:a67:ed4e:: with SMTP id m14mr7308929vsp.40.1617729489631; Tue, 06 Apr 2021 10:18:09 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 6 Apr 2021 10:17:57 -0700 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000927d6105bf50ff6a" Archived-At: Subject: [Emailcore] IETF conflict review for draft-crocker-email-author 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, 06 Apr 2021 17:18:15 -0000 --000000000000927d6105bf50ff6a Content-Type: text/plain; charset="UTF-8" This document is being processed via the ISE and thus is slotted to be evaluated by the IESG for conflict with existing work. I'm confident that EMAILCORE is not chartered to take this up, and I've already submitted a position that it is somewhat related to what's going on in EMAILCORE (and in DMARC, which is more of a direct hit) but that its progress through the ISE will not interfere with the work being done here. If I've got that wrong, please let me know soon. Thanks, -MSK --000000000000927d6105bf50ff6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This document is being processed via the ISE and thus= is slotted to be evaluated by the IESG for conflict with existing work.=C2= =A0 I'm confident that EMAILCORE is not chartered to take this up, and = I've already submitted a position that it is somewhat related to what&#= 39;s going on in EMAILCORE (and in DMARC, which is more of a direct hit) bu= t that its progress through the ISE will not interfere with the work being = done here.

If I've got that wrong, please let = me know soon.

Thanks,

-MS= K
--000000000000927d6105bf50ff6a-- From nobody Wed Apr 7 14:15:18 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 7F5AB3A2A22 for ; Wed, 7 Apr 2021 14:15:16 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 4-72XojivyWj for ; Wed, 7 Apr 2021 14:15:15 -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 0ABEF3A2A23 for ; Wed, 7 Apr 2021 14:15:14 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lUFW5-000CGe-CN; Wed, 07 Apr 2021 17:15:13 -0400 Date: Wed, 07 Apr 2021 14:58:40 -0400 From: John C Klensin To: "Murray S. Kucherawy" cc: emailcore@ietf.org Message-ID: <4A7096D4261E34E57A9FC660@PSB> In-Reply-To: References: 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] IETF conflict review for draft-crocker-email-author 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, 07 Apr 2021 21:15:17 -0000 --On Tuesday, April 6, 2021 10:17 -0700 "Murray S. Kucherawy" wrote: > This document is being processed via the ISE and thus is > slotted to be evaluated by the IESG for conflict with existing > work. I'm confident that EMAILCORE is not chartered to take > this up, and I've already submitted a position that it is > somewhat related to what's going on in EMAILCORE (and in > DMARC, which is more of a direct hit) but that its progress > through the ISE will not interfere with the work being done > here. > > If I've got that wrong, please let me know soon. Murray, While I agree with your analysis and conclusion above, I'd encourage you think about a closely-related problem. There is a long-time principle about email protocols [1], most explicitly first expressed in RFC 1425 but predating it, that complexity is the enemy of interoperability and protocols that work well and often the friend of those looking for opportunities for attacks. While there are many advantages of splitting email work up into multiple WGs, some even not in ART, one disadvantage is that we may end up with no good place for someone to argue that, what a particular proposal can be implemented and might work as claimed, it just is not worth the added overall complexity. Those are special concerns when we either change the semantics of an existing feature or consider adding a new feature that does what an older one was expected to do (or did do for a while) without deprecating the original feature. I don't have a good idea how to address that issue or parsimony in our feature set. Perhaps the IETF is in need of a Devil's Advocate for changes/ enhancements/ additions to existing protocols [2]. best, john [1] It has been suggested many times that the same principle should apply to all Internet-related protocols or at least those of which the IETF has any influence, but I'd prefer to avoid boiling that ocean today. [2] Anyone not knowing the origins of that term/role might want to look it up before jumping to conclusions about what I'm suggesting. From nobody Fri Apr 9 10:11:39 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 79CB13A2801; Fri, 9 Apr 2021 10:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <161798829345.21494.544278678507252050@ietfa.amsl.com> Date: Fri, 09 Apr 2021 10:11:33 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-as-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 17:11:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Applicability Statement for IETF Core Email Protocols Authors : John C Klensin Kenneth Murchison E Sam Filename : draft-ietf-emailcore-as-01.txt Pages : 7 Date : 2021-04-09 Abstract: Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emailcore-as-01 https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-as-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 14 09:12:59 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 BEE4F3A1583 for ; Wed, 14 Apr 2021 09:12:57 -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 ZOw6E-BKogF0 for ; Wed, 14 Apr 2021 09:12:56 -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 35FEE3A157E for ; Wed, 14 Apr 2021 09:12:56 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lWi8M-000GRk-Pm for emailcore@ietf.org; Wed, 14 Apr 2021 12:12:54 -0400 Date: Wed, 14 Apr 2021 12:12:49 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] RFC 822 dates considered harmful ? 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, 14 Apr 2021 16:12:58 -0000 Hi. I'm not sure what the right answer is to the question I'm about to ask, but it feels like it is necessary to ask it. The specification of RFC 5322 [1] is, as recently discussed on the ART list, an artifact of a much earlier time [2]. It is confusing to both computers and humans and annoying to parse [3]. The specification itself is often violated, with sometimes appearing instead of as required by the spec language and, more often, local terminology or abbreviations for and periodically creeping into header fields rather than merely in presentation in MUAs. While RFCs 6531 and 6532 do not address dates at all, it seems likely that the situation will get worse as we see SMTPUTF8 (EAI) implementations whose authors base them on what they think the specs say (or should say) rather than carefully studying those specs and their interactions with 5321 and 5322. So, what is to be done? Possibilities include: (1) Ignore the issue and hope it goes away or, at least, does not get worse. (2) Make some comments, probably in the A/S, about the importance of understanding and following the specs in this area (and hope someone notices) and probably warning about the (additional) confusion and other consequences of not doing so.. (3) Strongly encourage the use of an ISO 8601 date-time in a comment after the required field, specifying that it should use UTC ("Zulu") time only. (4) Change the syntax to what we would, I think, specify today, defining the current syntax as an obsolete feature and perhaps encouraging its inclusion in a comment. Personally, I have not reached a conclusion about preferences among (2)-(4) (much less options that have not come to mind as I wrote this note), but the more I think about the combination of Internet Standards we don't expect will be revised again (ever) and an increasingly global, multilingual, and multicultural Internet, the more the first option feels irresponsible to me. And, before the question is raised, I believe the current syntax has proven itself to be confusing enough and that there is sufficient non-conforming behavior out there to put consideration of the issue in scope for the WG. best, john [1] RFC 5322 and draft-ietf-emailcore-rfc5322bis-01 Section 3.3. [2] See https://mailarchive.ietf.org/arch/msg/art/NXIKnXDxgF7-RIMSUoYV04adMXk/ [3] See, e.g., https://mailarchive.ietf.org/arch/msg/art/AHEKrg1Sr98KrLWyAPWCE7umOYM From nobody Wed Apr 14 11:30:45 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 399023A1AAD for ; Wed, 14 Apr 2021 11:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=tluvdOf8; dkim=pass (2048-bit key) header.d=taugh.com header.b=HwWkkFK0 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 0mHDKP1lya94 for ; Wed, 14 Apr 2021 11:30:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23DE3A1AAB for ; Wed, 14 Apr 2021 11:30:37 -0700 (PDT) Received: (qmail 48068 invoked from network); 14 Apr 2021 18:30:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=bbc1.607734ca.k2104; bh=s7BricYkcOi6XMvgaShkIGpYXbYximkBYK9fJW4kaI0=; b=tluvdOf82WsWZWKHbg5CcTfjDtVcLaMgZ3IV1XhNeqYUjxjcu39BPsFMYkW7OovjuYvW3lt+wERR3hEXQfZKUoizX9hg8HuyxOylWh2uWjfwDUyQuCiZMo3UFPfSET8zHuG2Mc3IKaOx/ucStO80V7jtySTYEennFuJBdVh3caJGMGCCCBMqT2w8DNk5BxM8LzcLwQZuWcQMwIlSXIJC5RWtlLJnFsHKXsm5IaCald1GbZl4azHD8LtvNBb1lQIS5xqbAijPgW45zstV4WI3ZqDwLk7bG0DA1vpvmZGXORRRAeyv97faYLIyYUghT1Q9jWQsXYHnZ3QAZm/0DHm30A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=bbc1.607734ca.k2104; bh=s7BricYkcOi6XMvgaShkIGpYXbYximkBYK9fJW4kaI0=; b=HwWkkFK0NQPVn+FjawXvMRRPgWt/oQbQkNs3/X4tPZX2Sens3amxuQNUZ7mgi2B3HZbP/G3JgffK+IOf+HTmTzWZmB+5wiWLWA7P3/jOrNIzVrxtKCjoqUnzk+eY/Pa1qG6xb3QCD+/R1i870TBRfLn3RCKtuocB+v2tRIX0GmEPiMcJUUDwjkBdTMSOTKAuHmDCKYWFnsxf1Y4JyFNNG58OMzTETLOlpPXC94gfz8kIIIL2pJ+ywoTQaGuHiuii/wx9xeIhAqI4krLGNkV7r75pd38f7KyMOHlAgL3M0DgIC2Ej0Hh0BVw/0t78fDf4A3FNJaT8v6noomRkutCfKA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Apr 2021 18:30:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 11F7272E3B50; Wed, 14 Apr 2021 14:30:33 -0400 (EDT) Date: 14 Apr 2021 14:30:33 -0400 Message-Id: <20210414183034.11F7272E3B50@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 14 Apr 2021 18:30:43 -0000 It appears that John C Klensin said: >(2) Make some comments, probably in the A/S, about the >importance of understanding and following the specs in this area >(and hope someone notices) and probably warning about the >(additional) confusion and other consequences of not doing so.. If we were starting over I agree that we should use ISO 8601 dates. But we aren't, and I don't see how we are going to get MUAs and a zillion random webmail programs to recognize an incompatible format. How about if we pare down the definition of date-time to the minimum DD Mon YYYY HH:MM:SS +0000 and deprecate everything else including the optional day of week and anything other than UTC. I would think this would be easier to explain and easier for people to get correct. I suppose we could define a conventional comment for the ISO date, something like this: DD Mon YYYY HH:MM:SS +0000 (ISO:yyyy-mm-ddThh:mm:ssZ) but I don't see much point. There is tons of code that can parse the existing date format so the main point is to make it easier for people to generate that format correctly. We might also add a note that the date-time is primarily intended to be handled by software, not displayed directly, and software will generally display it in a format convenient to users, e.g., in the local time zone. R's, John From nobody Wed Apr 14 12:50: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 CF0833A1D79 for ; Wed, 14 Apr 2021 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JCt7EfmZ_ih4 for ; Wed, 14 Apr 2021 12:50:27 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AE53A1D74 for ; Wed, 14 Apr 2021 12:50:26 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id D17A5492F; Wed, 14 Apr 2021 21:50:23 +0200 (CEST) Date: Wed, 14 Apr 2021 21:50:23 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210414195023.GA30048@hjp.at> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 14 Apr 2021 19:50:32 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-04-14 12:12:49 -0400, John C Klensin wrote: > I'm not sure what the right answer is to the question I'm about > to ask, but it feels like it is necessary to ask it. If you knew the answer you wouldn't have to ask ;-). > The specification of RFC 5322 [1] is, as recently > discussed on the ART list, an artifact of a much earlier time > [2]. It is confusing to both computers and humans and annoying > to parse [3]. The specification itself is often violated, with > sometimes appearing instead of > as required by the spec language and, more often, local > terminology or abbreviations for and > periodically creeping into header fields rather than merely in > presentation in MUAs. Is this actually I problem these days? I remember that problems like this were quite common in the 1990s (probably bacause programmers were unfamiliar with the concept of locales at the time), but I don't remember when I last stumbled across a malformed date in an email header (it is of course possible that I simply don't notice because the software (including parsing libraries) I use is more forgiving than it ought to be). hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmB3R3kACgkQ8g5IURL+ KF23YRAAgovJQ3ahU1jizwWRwdL++TQttMPgDUWyOkvLvDbPIva8nvfYWIAPlu9B IB7YifpJ1lwyBeDvoBNEm/0Vo3u7H68nnoaX4FxDF+1FQNADN64vu6i9915avLib JvdAJb7v6J+TiV8ps8ZwMQUdUL/niL32olJ9LX1YwAaHz1crqfXQGpCe4KUNmlTf 79c4tBGj89wCj14raKkCrFJCWLsh1miNPgjXaoIatBSjcRJcvIdSZHsDA3qLqj6k CUQRmAVCGAJNKTUsAkV+9Bj80jQTaNlbjjFsZ1/5YdCALDpLTQ+LTwLvBKkSNZ0n gfVt0962/7Q/KFhQNbFFPn87cK/ZJzZfH13eTRVw7JY9SS8Tx+Lg4NZbB1PtGEUy 8a4zGKiKtrZ07V3ztKwG2+CBUDOxo2rWCSUPJPkL2k95vVPUYfY4HVGFIWjuMHmb AT/sij6uarLdVvVBbQLfF5gYjIHWPg/UKZCCK9bbSruqwreP7GV/3ocXW6HzAq1O jfQc2f0dVf2/TknouBHLBAcMq1/Cv12BJfirFRda1f+JHybbtRK5qERf4wgvhguz P/o7OPBicCbLPh7XuogYpTvo6mXKSpXOfxnS77X+2z0DfKAWanxep8fL1St7GzYj vw25B9O6p5/3uASsMKE9xBANaX/HIK+CV28S8Wb5EHfIZi4dCSg= =jPP2 -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Wed Apr 14 13:59:15 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 509953A1F92 for ; Wed, 14 Apr 2021 13:59:13 -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 (1024-bit key) header.d=drkurt.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 c1m631PAhHj6 for ; Wed, 14 Apr 2021 13:59:08 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 9D2FE3A1F8F for ; Wed, 14 Apr 2021 13:59:08 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id b17so18321537ilh.6 for ; Wed, 14 Apr 2021 13:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gQ0X0swMt7/nSYx4r3NX/FAr9MEHKx8urFxHKyqEk3Y=; b=bBdwb7pC5wwSgxp4EaHmEG+uC262XT/zDn2gi0ql0j5Bvjx0+bBOVGkaiqvFyvAVV7 FkwHyylrAiOZXDhpCXyxC8AR4+bM5lZfMQM+kJ8Z6RcBYpv/Tj7etIbM9r7cD5aBcct5 o2g9nnt8leeuoCOI2fBBa9WEsreTG/wOB//DY= 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:cc; bh=gQ0X0swMt7/nSYx4r3NX/FAr9MEHKx8urFxHKyqEk3Y=; b=AItXXIVSIOpq7bvxXT2NqYBLRsIjvfMcTYNnsTJj8X5fPr6JVb+d/BHoxczA0g19ex HQwO78ZWymHYeFGSGY+xmsYlldtSaLHuATmHkbw4PLDzXuOet8XEPMyMF75uKJ0jYbMu 6WGknC5z1rBiyeufa4vICUzRUhnzPqfSdx770vjGvVhKS6paFEd/8ZRJAC5FO7rSNkJT KEZwRnAWOJe57iH6LBmJaYCgi/3qJBM0MCVDlavy2CqDdsNfWzQKMPU+w/gDf7WomsS1 Ih3scnQDi9ckJ8d8eiHA2XIWfj/Z9watNvNlrCbQpPqle8FV7by0XSq2lUbKZ0VmO/gj BzmA== X-Gm-Message-State: AOAM5327yz/AELl/NrMW9LR1zKyJN8ybC8EaqdQATK0x7HVFNSAV5eBU oBuAzY+fvl+DBKlqwckoYXJ6Ba6W8Vf4vAhQlNd5Iw== X-Google-Smtp-Source: ABdhPJybaSgc5vTzDa6BBV9KvGcipPUzcbcJyqXPlMdjKdPPQhEblFJWggnoliEMcGB3BFBCIqWHGw+DGDstZmZdqfk= X-Received: by 2002:a92:1950:: with SMTP id e16mr154388ilm.120.1618433947040; Wed, 14 Apr 2021 13:59:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (IETF)" Date: Wed, 14 Apr 2021 13:58:57 -0700 Message-ID: To: John C Klensin Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000081940005bff50437" Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 14 Apr 2021 20:59:13 -0000 --00000000000081940005bff50437 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 14, 2021 at 9:13 AM John C Klensin wrote: > > (4) Change the syntax to what we would, I think, specify today, > defining the current syntax as an obsolete feature and perhaps > encouraging its inclusion in a comment. > I'd be strongly in favor of option 4 but strike the idea of the additional comment. Any mail system/MUA which does not adapt is apparently no longer being maintained. We know that there are a plethora of sending systems in that state but that's what recognizing the old format as obsolete is for :-) --Kurt --00000000000081940005bff50437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 14, 2021 at 9:13 AM John C Kl= ensin <john-ietf@jck.com> wr= ote:

(4) Change the syntax to what we would, I think, specify today,
defining the current syntax as an obsolete feature <delete this>and p= erhaps
encouraging its inclusion in a comment</delete this>.

I'd be strongly in favor of option 4 but strike th= e idea of the additional comment. Any mail system/MUA which does not adapt = is apparently no longer being maintained.

We know = that there are a plethora=C2=A0of sending systems in that state but that= 9;s what recognizing the old format as obsolete is for :-)

--Kurt
--00000000000081940005bff50437-- From nobody Thu Apr 15 09:42: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 43FE23A266C for ; Thu, 15 Apr 2021 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cketti.de 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 OS_5II9VbDOT for ; Thu, 15 Apr 2021 09:42:18 -0700 (PDT) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20]) (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 49FAF3A2670 for ; Thu, 15 Apr 2021 09:41:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618504907; cv=none; d=strato.com; s=strato-dkim-0002; b=NIA3aNFR/U4s7ex38U91POaIcg9njl9TRne1tNPRdrK0cGHuxg612IuSHjtSyLo4eq Re2Dz17FvFcjkhXH5SI8gzKm8RdB4sPfFBb1DMvBInzhGXo6LCReWm7cONu2I6/yHy/7 aQ3tMXl/NI858tdEcZozuOtOjs+nXUJQVfkGDXaKMYRUmuDUgbx12B9CMHCHH8dbFxyQ kP//fJMZgawnJNRcJbzBcSErxEpu9vd5OsgV/CyamRjO8EwZ3p8FCDHofSjMRVacyfT5 XvFV2ZYFXPQbrYSE1cM3f+1m07GFgfoIDU19+qyTZWCYV+LclPnyHmKSC5bEgt1pP66b 6FAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1618504907; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:Date:Message-ID:To:From:References:Subject:Cc:Date:From: Subject:Sender; bh=ZNywoZWykei/tBGldUtHMyurdSbcEFcXMEt0pLLavSI=; b=OqmAoxc90SmMoOdWUZgifWH9Z4EOZe9raE/21gQa90/P2HIR2qLn2yqziGbD/j9T5N H1q1Ic82xT2HvE83QLpbAh4rT5x2k3EgcpqacMI2uMvvanIUm0gqhxLfzSIRwSG2JDvu zij49CNlQeO86nuolUc+NbJcWARFt9Djq9sxjEysDFfW2Hx0Cu7Q5Wgp09jN0gybxp6S eq+OklLKvL7/eZPqd/hie6qiwSZdWOYKRg35ODz2RdMCNBW2bfa4WMFXRUOnIA0uUv6g 5kw8md1E8xoe+0dBl1J51lui/ZXNJSvOPY/Bd/NjPDOYsu+I9naNS6Z4BjW06znEovB+ 8q2A== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1618504907; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:To:From:References:Subject:Cc:Date:From: Subject:Sender; bh=ZNywoZWykei/tBGldUtHMyurdSbcEFcXMEt0pLLavSI=; b=SO32k+fAKwJ6mugdOBdSEiz8/TvfaAk/lFtkRvcslLZpGIDh33aOiY8Ahs0RWsmggD 0wr9x6aENBWDBBcs46jul4AL08+iRQ9A2xfdAoWOht9zYunOle6sGL2pw0lTKwrqqnLg kh3cZBFBCy4kBW0ji8is18si70ljiLT0pVrrcoSVqQjoRmH/Y844NWwtSzIyGKUGaPrx htqBYaaIR77hnRd4iYHziRUS8vPDO3RstdQbrKUXJ7V9ppbYy2HekI95o8tHQ0QA9OCY Ya6hdqxh7EoASrZO5yAOEOyf6k9gdJ8w46U9jXCGJBWejha/Ow//fbIW7gJXHFkZ7g0y bLkA== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oIudZGrZypc/JjmcOJ5vxm5IgIT1ryfHauqKYXVjn5sGlrgw0ZqXNs=" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2454:4a6:3a00:ec85:e5dd:2e0b:5e26] by smtp.strato.de (RZmta 47.24.3 AUTH) with ESMTPSA id 609ffbx3FGfl4K7 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 15 Apr 2021 18:41:47 +0200 (CEST) References: From: cketti To: emailcore@ietf.org Message-ID: Date: Thu, 15 Apr 2021 18:41:46 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 15 Apr 2021 16:42:23 -0000 On 2021-04-14 18:12, John C Klensin wrote: > So, what is to be done? How about a slightly different approach? (5) Define new header fields, move current ones (as far as I can tell this concerns "Date" and "Resent-Date") to obsolete syntax. Define a transition period where MUAs should use both variants when creating messages. After a cutoff date MUAs should only create messages using the new header fields. When reading messages and the new header fields are present MUAs must use those (and ignore the old header fields). The fallback behavior in case the new header fields contain invalid values and old ones are present should probably be defined. My preference would be not to fall back to the old header fields. That way problems with generating the new header fields are more likely to be detected before MUAs stop including both variants. -cketti From nobody Thu Apr 15 11:53:28 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 CF03C3A2ACC for ; Thu, 15 Apr 2021 11:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=KHsMVkbD; dkim=pass (2048-bit key) header.d=taugh.com header.b=J4A2OPs1 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 b2i_PEDQ4Nb5 for ; Thu, 15 Apr 2021 11:53:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B773A2AD1 for ; Thu, 15 Apr 2021 11:53:03 -0700 (PDT) Received: (qmail 33316 invoked from network); 15 Apr 2021 18:53:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=821b.60788b8c.k2104; bh=+VddXfGGDlkWmkZxIOZVauqFFz97O2uZ3YJUpHGc+dw=; b=KHsMVkbD9kpgf1ZRTYNYmczrZRePFh8Yd8N4o4bpwXXRu9KJuQGJjLOpC3ag/W0ubnetjqh3VxkeEWyKheBdK47rf+qZmCMK8Al9JqDL8ivYyPr0qxRG2O/Oyu8BDGG/Eur2hks/VppwpL4szyXnJnW0J36brCzRx8K1UNWR5IwzWVmNS7MldIveoaxjBre3DETJHevtEnjpOy5k4McatlcJ/eSvZgB+Z4zVZAholY4U4+bGuHJT1J92clJ8Fm5wNJ47d7RPN5HFGBuiC+3qa04JCzx39gJfOgKB5Pwsjt5XxXIjMyr9IVqVcUqHYK8VQi6qxmDrVO91y01PcDNxow== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=821b.60788b8c.k2104; bh=+VddXfGGDlkWmkZxIOZVauqFFz97O2uZ3YJUpHGc+dw=; b=J4A2OPs19iGZ5rJN/L+zwzXv+ltBioUPOJNXH+rZA0AuXL7RnxGkblwHWnITc/THy+pAnRQvFa7f7piVwdyUfgdeBZ+Nqs6ZcW/QG7zCtcKYirjiB4nujd1W4A28gqYHAN0rttgrzrU3NIwCuF7gsr+wg1uIJSV+EAMi8spQTlaMtABreRQLIJ1Rgx1DfTyHjWLeMBUuJS+T+hrZInPMRJP8Mu2pLEvcdTrxCrI8ka08ZUPy6sNzq8UrmVjWbgjWFFb5RFj8xt9rLYn+u0ca/s1FPf5REbv+cAzRQSo1IZ2BLnqVuKk1zVgPD+SsNiNzWz4TD5Yq6RWjVWeB6plTkw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Apr 2021 18:53:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 8A4AA72F5422; Thu, 15 Apr 2021 14:52:59 -0400 (EDT) Date: 15 Apr 2021 14:52:59 -0400 Message-Id: <20210415185259.8A4AA72F5422@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ck@cketti.de In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 15 Apr 2021 18:53:26 -0000 It appears that cketti said: >On 2021-04-14 18:12, John C Klensin wrote: >> So, what is to be done? > > >How about a slightly different approach? > >(5) Define new header fields, move current ones (as far as I can tell >this concerns "Date" and "Resent-Date") to obsolete syntax. Define a >transition period where MUAs should use both variants when creating >messages. After a cutoff date MUAs should only create messages using the >new header fields. That date would be about 2050, if we're lucky. Our experience with forcing pepole to change, particularly when the current situation is not broken in a way that affects meant people, is not encouraging. R's, John From nobody Thu Apr 15 20:31:40 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 1F4E63A11BF for ; Thu, 15 Apr 2021 20:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 dEgd6CxdXGLY for ; Thu, 15 Apr 2021 20:31:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601823A11BC for ; Thu, 15 Apr 2021 20:31:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lXFCe-000PaC-E1; Thu, 15 Apr 2021 23:31:32 -0400 Date: Thu, 15 Apr 2021 23:31:25 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org cc: ck@cketti.de Message-ID: <1257A8059C18A9A236CE9F44@PSB> In-Reply-To: <20210415185259.8A4AA72F5422@ary.qy> References: <20210415185259.8A4AA72F5422@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 16 Apr 2021 03:31:39 -0000 --On Thursday, April 15, 2021 14:52 -0400 John Levine wrote: > It appears that cketti said: >> On 2021-04-14 18:12, John C Klensin wrote: >>> So, what is to be done? >> >> >> How about a slightly different approach? >> >> (5) Define new header fields, move current ones (as far as I >> can tell this concerns "Date" and "Resent-Date") to obsolete >> syntax. Define a transition period where MUAs should use >> both variants when creating messages. After a cutoff date >> MUAs should only create messages using the new header fields. > > That date would be about 2050, if we're lucky. Our experience > with forcing pepole to change, particularly when the current > situation is not broken in a way that affects meant people, is > not encouraging. If I had to make a guess, 2050 is far too optimistic. That is why I was guessing that, if we were going to do anything at all, it would have to be something involving a transition and/or side-by-side strategy that people could add if they got customer pressure and/or happened to be opening that area of code anyway. best, john From nobody Thu Apr 15 20:37: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 B36023A11F6 for ; Thu, 15 Apr 2021 20:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 P8hxtKRK7bBP for ; Thu, 15 Apr 2021 20:36:59 -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 4E4B83A11E2 for ; Thu, 15 Apr 2021 20:36:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lXFHt-000Pbp-H8; Thu, 15 Apr 2021 23:36:57 -0400 Date: Thu, 15 Apr 2021 23:36:50 -0400 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: In-Reply-To: <20210414195023.GA30048@hjp.at> References: <20210414195023.GA30048@hjp.at> 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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 16 Apr 2021 03:37:04 -0000 --On Wednesday, April 14, 2021 21:50 +0200 "Peter J. Holzer" wrote: > On 2021-04-14 12:12:49 -0400, John C Klensin wrote: >> I'm not sure what the right answer is to the question I'm >> about to ask, but it feels like it is necessary to ask it. > > If you knew the answer you wouldn't have to ask ;-). > > >> The specification of RFC 5322 [1] is, as recently >> discussed on the ART list, an artifact of a much earlier time >> [2]. It is confusing to both computers and humans and >> annoying to parse [3]. The specification itself is often >> violated, with sometimes appearing instead >> of as required by the spec language and, >> more often, local terminology or abbreviations for >> and periodically creeping into header fields rather >> than merely in presentation in MUAs. > > Is this actually I problem these days? I remember that > problems like this were quite common in the 1990s (probably > bacause programmers were unfamiliar with the concept of > locales at the time), but I don't remember when I last > stumbled across a malformed date in an email header (it is of > course possible that I simply don't notice because the > software (including parsing libraries) I use is more forgiving > than it ought to be). I haven't seen the problem since, IIR, this afternoon. It most commonly shows up in a case that one can argue is just an MUA botch rather than a 5322 violation, and that is replies where the canonical date on the incoming message is localized and then not un-localized on the way back out. As I think I mentioned in my note, I think I've also seen SMTPUFT8 /"EAI" implementations that have gotten confused and those are, by definition, a lot more recent than the 1990s. john john From nobody Fri Apr 16 10:03:19 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 BC46D3A2CAF for ; Fri, 16 Apr 2021 10:03:17 -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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cketti.de 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 JDBL8WQzG123 for ; Fri, 16 Apr 2021 10:03:13 -0700 (PDT) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.23]) (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 D66103A2CAE for ; Fri, 16 Apr 2021 10:03:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618592589; cv=none; d=strato.com; s=strato-dkim-0002; b=hp/yUFtYMC7JVLSdKtghppuwSFOiZJwkKtxBrZXjuABDAjaIEufdFAPj26JKbNJos9 SS9OsKcAnzzA59fogfnP/3zk9sbKYi4Gk9mXoXl/aH11jteM6pOFpqw0mPXPH/Fi6Iqs 6R7IRtlZpy4AWg2nDBrS2nnzQk9ykES44qGNKHoM7CkQrgQ5TG9B1gQ1UEBvGxbU7mY1 ReYOgLXIF2IYXiUJcG7BtBrOF8s2ceUbIuCQw6lfVjsuZcMdATl/VATzvwwf/e+jsOm3 AwPhcJ939X6WAiMbWcuohSFZYQYd8+k0stE76ch0FCoSXDaQrudUUESPtTbPwBNFoqQG xKww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1618592589; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:Date:Message-ID:From:References:To:Subject:Cc:Date:From: Subject:Sender; bh=uS6j0fea8ejog/hhZ+Cg8c23TG0zGaK2tnalg37NdHw=; b=qGB5vYdB6fV8oMH0shRoig2L5XSVWp+dBCEo4BfmQQtd/pYi1NAXa9jQso/PB27Va1 5gTIZTN+xX6CD9DIJ2jBvysNQYpWVa36MWxdHmN5512QhTEKSFCTZpfjEgLX4L1QA7a3 Ia6wWaGXv77xts9vwgUCKTYqhbDObtO7x9cb8MQcNEGTjd7c/oVVHomDLayo/AzNRNp+ W9l8PBAEPWHaCkdQz0s5QW2xORHXRFyxx1/j+fpS2e0OgemDjNvm/WyYL9QBD5fwYRTA u13E0cLShaSThwlup1dtrafwHAqTrrQHMv3Ji1LE3fWAA+xENvpKNI1dmfMPahRBClkS wAnQ== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1618592589; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject:Cc:Date:From: Subject:Sender; bh=uS6j0fea8ejog/hhZ+Cg8c23TG0zGaK2tnalg37NdHw=; b=XkWDswaoODarc+hSikAuNYJyMH/D7Kzhhk+x8EpGXVcZYCGfQMidFD5QZcvD+j7XT1 /zPgpttKBRmFxtRFiQNSSG6VUVUaYQpGvnvhSp6vTxdP1j51RtdKfk7txKLxtUSdNznI EguZQfH0JY9ZEtD+7JX+ZmKNpcdckSmVFbFea7zMOMZOV15+5/jyhYDcTXWABDb61Zg9 kMzpGlfEJ4HQGRWB8Yz4nyhNTvGUH6ukAdj7yp48RttRw6hdW3a2uAaPTOMdYfmozmQM wPfFqPrGPz9sSIcndCL11MaHpfSGLvIgpqrVYcfEGffy/66HnnY/0aW839c6PzD2G/B/ Rtog== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oIudZGrZypc/JjmcOJ5vxm5IgITh7uVEautJdOEKJNgoIeaOE7CM/0=" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2454:4a6:3a00:4d29:b925:3e81:1b61] by smtp.strato.de (RZmta 47.24.3 AUTH) with ESMTPSA id 609ffbx3GH398e8 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Fri, 16 Apr 2021 19:03:09 +0200 (CEST) To: emailcore@ietf.org References: <20210415185259.8A4AA72F5422@ary.qy> From: cketti Message-ID: <73c14f8c-4e96-4a4d-035d-5414682c286b@cketti.de> Date: Fri, 16 Apr 2021 19:03:08 +0200 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: <20210415185259.8A4AA72F5422@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 16 Apr 2021 17:03:18 -0000 John Levine wrote: > It appears that cketti said: >> On 2021-04-14 18:12, John C Klensin wrote: >>> So, what is to be done? >> >> How about a slightly different approach? >> >> (5) Define new header fields, move current ones (as far as I can tell >> this concerns "Date" and "Resent-Date") to obsolete syntax. Define a >> transition period where MUAs should use both variants when creating >> messages. After a cutoff date MUAs should only create messages using the >> new header fields. > That date would be about 2050, if we're lucky. Our experience with > forcing pepole to change, particularly when the current situation is > not broken in a way that affects meant people, is not encouraging. There's no point in picking a date where you estimate a significant number of implementations would have switched to the new behavior when it's convenient for them. The idea of picking a deadline is to add pressure. Maybe there is no pressure to change at first. But when MUAs start only using the new header field things will break for clients that didn't adapt. At that point they'll either update very quickly or they'll be left behind. Of course this assumes that at least one major player adopts the change in order for there to be pressure on others. But I agree that it's probably not worth it for date-time header fields. From nobody Fri Apr 16 10:52:21 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 961BC3A2E19 for ; Fri, 16 Apr 2021 10:52:19 -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 MknNC3UMYdU3 for ; Fri, 16 Apr 2021 10:52:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45573A302C for ; Fri, 16 Apr 2021 10:51:50 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lXSdB-0003io-DL; Fri, 16 Apr 2021 13:51:49 -0400 Date: Fri, 16 Apr 2021 13:51:43 -0400 From: John C Klensin To: cketti , emailcore@ietf.org Message-ID: In-Reply-To: <73c14f8c-4e96-4a4d-035d-5414682c286b@cketti.de> References: <20210415185259.8A4AA72F5422@ary.qy> <73c14f8c-4e96-4a4d-035d-5414682c286b@cketti.de> 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] RFC 822 dates considered harmful ? 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, 16 Apr 2021 17:52:20 -0000 --On Friday, April 16, 2021 19:03 +0200 cketti wrote: > John Levine wrote: >> It appears that cketti said: >>> On 2021-04-14 18:12, John C Klensin wrote: >>>> So, what is to be done? >>> >>> How about a slightly different approach? >>> >>> (5) Define new header fields, move current ones (as far as I >>> can tell this concerns "Date" and "Resent-Date") to obsolete >>> syntax. Define a transition period where MUAs should use >>> both variants when creating messages. After a cutoff date >>> MUAs should only create messages using the new header fields. >> That date would be about 2050, if we're lucky. Our experience >> with forcing pepole to change, particularly when the current >> situation is not broken in a way that affects meant people, >> is not encouraging. > > There's no point in picking a date where you estimate a > significant number of implementations would have switched to > the new behavior when it's convenient for them. The idea of > picking a deadline is to add pressure. Maybe there is no > pressure to change at first. But when MUAs start only using > the new header field things will break for clients that didn't > adapt. At that point they'll either update very quickly or > they'll be left behind. > Of course this assumes that at least one major player adopts > the change in order for there to be pressure on others. On the one hand, your reasoning is quite consistent with the decision to hold a "flag day" on January 1 1983 on which carrying of NCP traffic on the Internet was discontinued. It is interesting (although probably not useful) to speculate on where we would be had the decision to do that not been made. E.g., if we look at the rapid and complete conversation to IPv6 and note that IPv6 has now existed longer than NCP lasted, it is tempting to conclude that we would probably be running dual-stack or NCP gateways and NATs to this day, eight bit address space and all. But there is no way to select and enforce such a deadline today. In a world of voluntary standards there is every reason to believe that the response to "those headers are obsolete and you MUST use this set" would be thanking us for our advice (or questioning our sanity) and then ignoring the new spec. And that is why, at least IMO, changes to existing, widely-deployed, and already standardized protocols should be documented with the compelling reasons for making the change. And the changes themselves should be designed to make it easy for older and newer implementations to co-exist. If the reasons are good enough, some implementations will add the new facilities and other implementation will do so, either for the same reason or for better compatibility with the enhanced features of the early adopters. And, then, if it takes the laggard implementations the 28 years John Levine posited to get around to making the changes... well, who cares other than their users?... and those users presumable could decide to vote with their feet. > But I agree that it's probably not worth it for date-time > header fields. Yeah. But the fact that it is not should not prevent us from discussing other types of changes/ improvements to those fields. best, john From nobody Sat Apr 17 04:33:52 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 71E423A1F14 for ; Sat, 17 Apr 2021 04:33:49 -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 2XitCkrqIMsF for ; Sat, 17 Apr 2021 04:33:43 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB12B3A1F13 for ; Sat, 17 Apr 2021 04:33:43 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 3C1814969; Sat, 17 Apr 2021 13:33:40 +0200 (CEST) Date: Sat, 17 Apr 2021 13:33:40 +0200 From: "Peter J. Holzer" To: John C Klensin Cc: emailcore@ietf.org Message-ID: <20210417113340.GA6196@hjp.at> References: <20210414195023.GA30048@hjp.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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: Sat, 17 Apr 2021 11:33:50 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-04-15 23:36:50 -0400, John C Klensin wrote: >=20 >=20 > --On Wednesday, April 14, 2021 21:50 +0200 "Peter J. Holzer" > wrote: >=20 > > On 2021-04-14 12:12:49 -0400, John C Klensin wrote: > >> The specification of RFC 5322 [1] is, as recently > >> discussed on the ART list, an artifact of a much earlier time > >> [2]. It is confusing to both computers and humans and > >> annoying to parse [3]. The specification itself is often > >> violated, with sometimes appearing instead > >> of as required by the spec language and, > >> more often, local terminology or abbreviations for > >> and periodically creeping into header fields rather > >> than merely in presentation in MUAs. > >=20 > > Is this actually I problem these days? I remember that > > problems like this were quite common in the 1990s (probably > > bacause programmers were unfamiliar with the concept of > > locales at the time), but I don't remember when I last > > stumbled across a malformed date in an email header (it is of > > course possible that I simply don't notice because the > > software (including parsing libraries) I use is more forgiving > > than it ought to be). >=20 > I haven't seen the problem since, IIR, this afternoon. It most > commonly shows up in a case that one can argue is just an MUA > botch rather than a 5322 violation, and that is replies where > the canonical date on the incoming message is localized and then > not un-localized on the way back out. I don't think I understand what you mean. "The way out" for a MUA would be either displaying a mail (which is outside of the scope of RFC 5322) or sending a mail (in which case it would generate a new Date header, not re-use one from a message it received). Can you be a bit more specific on what (presumably) happens here? I wrote a litte test script and ran it on about 70000 messages from the last 30 days (from two sites, mixture of spam and ham). By far the most common syntax error (202 occurences) was that the hour was only one digit (e.g. "5:12:34" instead of "05:12:34").=20 8 Messages didn't have a Date header at all. 3 had a negative hour (e.g. "Mon, 29 Mar 2021 -1:01:33 -0400"). 2 were missing the time zone. 1 had an invalid time zone ("EEST") 1 had the string "Date:" duplicated. I found no instances of localized day or month names. Both sites are in Austria, where English is not the primary language. > As I think I mentioned in my note, I think I've also seen SMTPUFT8 > /"EAI" implementations that have gotten confused and those are, by > definition, a lot more recent than the 1990s. Neither site supports SMTPUTF8, but I don't see how that would change anything (the Date header is normally created by the client or the submission server and not changed in transit). This is of course a very small and non-representative sample. I think it does illustrate that the problem is at least unevenly distributed, though. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmB6x48ACgkQ8g5IURL+ KF0gBRAAjGmzmWjl4tQJmCvmY50yOX8gxOZ3Ha5fL7U0mxdPuwbdZupOJ7UcW3Iw 3tNQ5EgmqKrOQhp/SKQn8Xwm/PC0tAXjftqCD9OTqDNDn9KC7FtE/SPug4xquvA8 xS0xvvXNV92dlvM6q/lVnig8in7P6f/wN4IRyH714BZ7I0wD3ps7z+bbBd7/uus5 oT/nX5cKo5IEkqu49DMiFOTFi71mjo337D5dofmyH2BkFiDiTMb+0Bhd1yV0jg8D LQj0ypqsAFaRtvsZJitfCdC6pWmB2xnOtlYW3YFqXoQPSvkM0lLikHCvolUpDV2+ GEU0sQNv7YPd3ORbTzdbKkF6TmTcFzPh+CQ2eFNX1Z/c96XBTubtQ+HAL4r1uaP7 AdG50fH9ySyGaKFNqA5JlWutbK2CiRrrGpSLZa6TqfYa7rjSH8B6KmNjStorPgzo isLcK7PKzLtr/qY6Pj4a2cBEeP8xr3sz3DG0EtaxGxi2RreE0BsMeUpx5Ws/gC4Y P3KhT/ncbnKB6+uEzRpNagyIjvr1pIqVf5/N4Wi8K7LPnjXKsK5VT1UFwFnezxI9 c9a/UCfkt1PcA9LkuGVbHIN2Rlcxjw8fjzprThknRwzcMrdFnyIEwXwSbtYW1tUE k+qnFa6LJh9jcS0OHINkqTfk/BvFA32Yya8xK8KxZzOsksaIz/I= =xg8e -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From nobody Sat Apr 17 08:15:18 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 9B7783A25EC for ; Sat, 17 Apr 2021 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 rv0TfCa6Qg5J for ; Sat, 17 Apr 2021 08:15:12 -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 DD29A3A25E9 for ; Sat, 17 Apr 2021 08:15:11 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lXmf8-000DXU-9o; Sat, 17 Apr 2021 11:15:10 -0400 Date: Sat, 17 Apr 2021 11:15:04 -0400 From: John C Klensin To: "Peter J. Holzer" cc: emailcore@ietf.org Message-ID: In-Reply-To: <20210417113340.GA6196@hjp.at> References: <20210414195023.GA30048@hjp.at> <20210417113340.GA6196@hjp.at> 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] RFC 822 dates considered harmful ? 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: Sat, 17 Apr 2021 15:15:17 -0000 Peter, First, let me concede, if I had not made it clear already, that really serious problems with the Date: header field, other than omitting it entirely, are rare. What I have seen is by no means a systematic sample and stretches back at least a year or three. Even then, your results are, with one exception, consistent with mine. And, again, my goal was to ask a question about whether we wanted to consider doing something in this area, not to advocate any particular course of action (or even any action). More inline below. --On Saturday, April 17, 2021 13:33 +0200 "Peter J. Holzer" wrote: > On 2021-04-15 23:36:50 -0400, John C Klensin wrote: >> >> >> --On Wednesday, April 14, 2021 21:50 +0200 "Peter J. Holzer" >> wrote: >> >> > On 2021-04-14 12:12:49 -0400, John C Klensin wrote: >> >> The specification of RFC 5322 [1] is, as >> >> recently discussed on the ART list, an artifact of a much >> >> earlier time [2]. It is confusing to both computers and >> >> humans and annoying to parse [3]. The specification >> >> itself is often violated, with sometimes >> >> appearing instead of as required by the >> >> spec language and, more often, local terminology or >> >> abbreviations for and periodically >> >> creeping into header fields rather than merely in >> >> presentation in MUAs. >... > I don't think I understand what you mean. "The way out" for a > MUA would be either displaying a mail (which is outside of the > scope of RFC 5322) or sending a mail (in which case it would > generate a new Date header, not re-use one from a message it > received). Can you be a bit more specific on what (presumably) > happens here? Maybe fuzzy thinking on my part in interpreting what I have seen. Maybe some members of the broad class of MUAs (see below) that are stranger than you assume. Probably you should just ignore that part of my comments. > I wrote a litte test script and ran it on about 70000 messages > from the last 30 days (from two sites, mixture of spam and > ham). > > By far the most common syntax error (202 occurences) was that > the hour was only one digit (e.g. "5:12:34" instead of > "05:12:34"). It that, or omission of the date header fields entirely (which I see more often but that just demonstrates that we are seeing different batches of messages), it would, IMO, still be worth a brief discussion of whether those things were worth pointing out (probably in the A/s) and either cautioning sending systems about getting it wrong or encouraging receiving systems to be extra-liberal. Again, recommending a discussion, not a particular decision. > 8 Messages didn't have a Date header at all. > > 3 had a negative hour (e.g. "Mon, 29 Mar 2021 -1:01:33 -0400"). > > 2 were missing the time zone. > > 1 had an invalid time zone ("EEST") > > 1 had the string "Date:" duplicated. > I found no instances of localized day or month names. Both > sites are in Austria, where English is not the primary > language. >> As I think I mentioned in my note, I think I've also seen >> SMTPUFT8 /"EAI" implementations that have gotten confused and >> those are, by definition, a lot more recent than the 1990s. > > Neither site supports SMTPUTF8, but I don't see how that would > change anything (the Date header is normally created by the > client or the submission server and not changed in transit). It changes two things. One is that a few SMTPUTF8 implementations (albeit ones with large numbers of users/customers) have either been fairly sloppy or have optimized for the perceived convenience of their users rather than for adherence to the strict letter of the standards. That is further complicated by an operational issue and/or a question about choices of mail models. Suppose a mail services operator runs their own mail repository which their users access only via web interfaces or clients that they supply. If one of those users sends a message to another, they are arguably not sending "Internet mail" and whatever they do is not constrained by either 5321 or 5322 (including "Date:". header field formats and dates in time-stamp fields if they used the latter at all). That view of the world would create a situation in which mail sent so a non-customer would, in the model of 5321, be passing through a gateway and that provider would be obligated to convert to standard form at the boundary. But we know of at least one large email provider who routinely ignores those requirements and lets their internal information and formats leak, so there is not much reason to expect that other providers will be more careful and scrupulous, especially when a higher percentage of their mail messages are among their users. And, btw, if that is a gateway situation, it is not even clear that, if time-stamp-like information is supplied for handling of the message before it passes into the Internet, the syntax and content of that information are constrained by 5321/5322 such that reinterpretation and conversion are required. The second is that, while I note your comment about English in Austria, the temptation and incentives for using local month names (and local day names when supplied) are much higher when those local names are in non-Latin scripts and especially when the local populations may not be even vaguely familiar with the English names. > This is of course a very small and non-representative sample. > I think it does illustrate that the problem is at least > unevenly distributed, though. Indeed. It may also suggest something that goes far beyond dates: It might be wise for 5322bis to be much more clear and forceful that its field names and keywords are fixed strings and that, while MUAs (or equivalent) are free to do whatever they like to present information in user-convenient localized form, their ability to do that is dependent on everyone following the rules about what goes over the wire. It may also suggest that the A/S offer guidance about what a receiving system should do if mandatory fields (including any of Date:, From:, and at least one of To: or Cc:) are missing. Do we have advice about whether such a system should make up values and insert those header fields and, if so, what information should it use to infer those values? Or do we prefer that the message be rejected as incomprehensible or otherwise managed as trash? best, john From nobody Sat Apr 17 13:11: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 C05BA3A30F2 for ; Sat, 17 Apr 2021 13:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7MNS9Uv98pTN for ; Sat, 17 Apr 2021 13:11:36 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859CB3A30F6 for ; Sat, 17 Apr 2021 13:11:36 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 7F748496E; Sat, 17 Apr 2021 22:11:33 +0200 (CEST) Date: Sat, 17 Apr 2021 22:11:33 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210417201133.GA1341@hjp.at> References: <20210414195023.GA30048@hjp.at> <20210417113340.GA6196@hjp.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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: Sat, 17 Apr 2021 20:11:42 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-04-17 11:15:04 -0400, John C Klensin wrote: > --On Saturday, April 17, 2021 13:33 +0200 "Peter J. Holzer" > wrote: > > I wrote a litte test script and ran it on about 70000 messages > > from the last 30 days (from two sites, mixture of spam and > > ham). > >=20 > > By far the most common syntax error (202 occurences) was that > > the hour was only one digit (e.g. "5:12:34" instead of > > "05:12:34").=20 >=20 > It that, or omission of the date header fields entirely (which I > see more often but that just demonstrates that we are seeing > different batches of messages), it would, IMO, still be worth a > brief discussion of whether those things were worth pointing out > (probably in the A/s) and either cautioning sending systems > about getting it wrong or encouraging receiving systems to be > extra-liberal. Again, recommending a discussion, not a > particular decision. Putting some emphasis on that in the A/S would certainly be a good idea.=20 We could also put a sentence like "Please note that the day and month names MUST be spelled exactly as specified and MUST NOT be localized" in RFC5322bis. However, I'm a bit dubious on whether it would help. It's already rather clear IMHO, and people who ignore what's already there are likely to ignore that extra sentence, too. As for a new date format, I don't think that would help at all. The current format is a bit baroque by current standards, but not that hard to produce or parse (at least if you ignore the obsolete forms), and as others have pointed out a new format would just be an additional format for decades, so it would decrease interoperability. (Speaking of decades: Can we get rid of the obsolete forms? The only obsolete feature I see with any frequency is "GMT" as the time zone.) > Suppose a mail services operator runs their own mail repository which > their users access only via web interfaces or clients that they > supply. If one of those users sends a message to another, they are > arguably not sending "Internet mail" and whatever they do is not > constrained by either 5321 or 5322 (including "Date:". header field > formats and dates in time-stamp fields if they used the latter at > all). That view of the world would create a situation in which mail > sent so a non-customer would, in the model of 5321, be passing through > a gateway and that provider would be obligated to > convert to standard form at the boundary. Gateways are of course always a bit tricky (I remember that it was often quite obvious that Lotus Notes was internally using a very different structure than RFC5322). I would generally expect the problem areas to be elsewhere, though. The date header is just a simple timestamp, nothing which requires much thought (OTOH, that might be the problem: Converting the MIME structure was discussed among senior developers; converting the Date header was probably assigned to the intern). > But we know of at least one large email provider who routinely ignores > those requirements and lets their internal information and formats > leak, so there is not much reason to expect that other providers will > be more careful and scrupulous, especially when a higher percentage of > their mail messages are among their users. And, btw, if that is a > gateway situation, it is not even clear that, if time-stamp-like > information is supplied for handling of the message before it passes > into the Internet, the syntax and content of that information are > constrained by 5321/5322 such that reinterpretation and conversion are > required. The second is that, while I note your comment about English > in Austria, the temptation and incentives for using local month names > (and local day names when supplied) are much higher when those local > names are in non-Latin scripts and especially when the local > populations may not be even vaguely familiar with the English names. True. But I notice that most MUAs don't just display headers as they are: They are parsed into some internal format and then that is rendered (possibly with localization) onto the screen. So there is no "From:" but an "Absender", and the email address may not even be displayed (only the name). Similarily, the Date header is usually converted to local time and displayed according to local conventions. (I'm using mutt, which is of course an exception.) For a system that is mostly an internal messaging system with an SMTP-Gateway bolted on I would expect that to be the case even more. For example, most traditional date formats are horrible for sorting. So internally they would probably use a nice monotonic numerical format (like Unix time_t or Julian days). But I don't know the internals of any such system, so this is just speculation. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmB7QNsACgkQ8g5IURL+ KF1ykBAAshbvUVrRSHcqeKc0jqfqY4k0iynOnQJQscoGxJlqtCJPKcVHxccnsrkf VHVXIAG5V0QRkGyWv0oDxHeJMDpGfNxWSW90w7FD9AGtjazZBjM5QMq7+6B18MJf 91rjY2SdrtJlxhEFHwUgWDnhRrKnBsyIAnd7gc9B0Gfjnav8sgZKvDU4RTuAALlS GJbpKMPr6YH8VN0Vs3j+i0rsMEjqMLRRF8SDdlv6kmwp/AJqYxIL/MqERhyeY31r 7qPN/Hh+/6Jf4DteWHKIWMs0lLfEGq9SMvqNH46dDJdivpkxDlZ2fM4AY0YM0hYj 1XKGzJM/Sl8U0wxPkX/vx3me6QxCqSp7n0MXwCGuBOLHAcz9ck7xCBuUrYd64Q/G x2ey13N+ztQlZmVHSXHh0GhPAlIReH94zt5xSXC7jvJMLgIdyLFllGjOOFHHUOow EgtV97K3WLIMD6YYTnMUX5ngFaqnD3MKDWuifgq+b8fnT16iMD9N3e7Dju31ZTGw //cZaBISo+SJZy/u8vhJbkuRwOAfML+5KrZq1m7n03HVAqHXnZ+LLYaAphO6O8D6 cxa0yER68w63TDrNc9wSdSILCIkpJeAU3NnF1ISxa5ctyPyjyO2yrZ91tub1MmGa mTFhjV/3gMOScewvkEwPQ/7x5Zt0rpL++QjDvha9BK/Jw291PYg= =uWmP -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From nobody Sun Apr 18 11:25: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 514D43A2272 for ; Sun, 18 Apr 2021 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[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, 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 isQU3F6Uh41W for ; Sun, 18 Apr 2021 11:25:30 -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 2D5873A2273 for ; Sun, 18 Apr 2021 11:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1618770320; bh=gKJG1NXh/BWSX1Amf5klK3YcOFK7jw7ZWCS7O05GQW0=; l=1051; h=To:References:From:Date:In-Reply-To; b=CmUXEOjeTTqcWqwck3ZMnhuuAsxwCrn0kgnni1kT/ydwLYBFWd8e7lEGZ4Ukk0Wmx 0PC3DumgdEXc642cf+acDfj9YUco9PD8UIQv/XuOkLWIAXoIkYks/9cubD3B7UQKxe gSXeWivIFEuaxcQgKg++O52fMa0WSuA8su3jDhjYkhtc6A2n4RzwpmwRHdzCj 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 00000000005DC0CD.00000000607C798F.0000520B; Sun, 18 Apr 2021 20:25:19 +0200 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sun, 18 Apr 2021 20:25:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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: Sun, 18 Apr 2021 18:25:36 -0000 On Wed 14/Apr/2021 18:12:49 +0200 John C Klensin wrote: > > The specification of RFC 5322 [1] is, as recently > discussed on the ART list, an artifact of a much earlier time > [2]. It is confusing to both computers and humans and annoying > to parse [3]. Is it? I don't think so. For one thing, sometimes I have to look at the Date: header in the raw message, because my mail client translates dates to the local timezone (see the very 1st line of this message). Thereby, the client hides what was the actual local time when the message was composed. In this respect, RFC5322.Date as-is carries more info than if it used UTC ("Zulu") time only. > (1) Ignore the issue and hope it goes away or, at least, does > not get worse. Which issue? jm2c Ale -- > [1] RFC 5322 and draft-ietf-emailcore-rfc5322bis-01 Section 3.3. > > [2] See > https://mailarchive.ietf.org/arch/msg/art/NXIKnXDxgF7-RIMSUoYV04adMXk/ > > [3] See, e.g., > https://mailarchive.ietf.org/arch/msg/art/AHEKrg1Sr98KrLWyAPWCE7umOYM From nobody Mon Apr 19 07:12: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 D1E193A32E6 for ; Mon, 19 Apr 2021 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, 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 RRUh0D61psgL for ; Mon, 19 Apr 2021 07:12:38 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830D03A3303 for ; Mon, 19 Apr 2021 07:11:39 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lYUcF-000Erc-8y; Mon, 19 Apr 2021 10:11:07 -0400 Date: Mon, 19 Apr 2021 10:10:47 -0400 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: In-Reply-To: References: 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 Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 19 Apr 2021 14:12:43 -0000 Again, not advocating a particular decision, just trying to be sure we all understand the question in the same way. ... --On Sunday, 18 April, 2021 20:25 +0200 Alessandro Vesely wrote: > On Wed 14/Apr/2021 18:12:49 +0200 John C Klensin wrote: >> >> The specification of RFC 5322 [1] is, as recently >> discussed on the ART list, an artifact of a much earlier time >> [2]. It is confusing to both computers and humans and >> annoying to parse [3]. > > > Is it? I don't think so. > > For one thing, sometimes I have to look at the Date: header in > the raw message, because my mail client translates dates to > the local timezone (see the very 1st line of this message). > Thereby, the client hides what was the actual local time when > the message was composed. In this respect, RFC5322.Date as-is > carries more info than if it used UTC ("Zulu") time only. Yep. Sometimes Zulu is best, sometimes you want to know the local time of the sender when the message was sent, and sometimes you want to know your (the recipient's) local time when the message was sent. The question I was asking was about moving to, or supplementing the date with, ISO 8601-formatted date and time, not eliminating the reference to local time, which is, at best, a separate question. >> (1) Ignore the issue and hope it goes away or, at least, does >> not get worse. > Which issue? The issue that dates, as specified in RFC5322, have poor internationalization/localization properties. Although, as you more or less point out, if one can parse them, one can convert to local formats and convert back -- that is about whether it is important to make a change, not about whether the format is inconvenient. best, john From nobody Mon Apr 19 07:36: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 ADA463A3467 for ; Mon, 19 Apr 2021 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=nZGGvO1/; dkim=pass (2048-bit key) header.d=taugh.com header.b=UzGLv3+I 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 FjVpP8oJSiw3 for ; Mon, 19 Apr 2021 07:35:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C263A3422 for ; Mon, 19 Apr 2021 07:35:25 -0700 (PDT) Received: (qmail 44095 invoked from network); 19 Apr 2021 14:35:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=ac3c.607d952b.k2104; bh=0jJdHA9EN1sZ/ywWw7Vy4ew6WwwdZM1pBziL/KfpLGc=; b=nZGGvO1/swYS4eJUijtsitZakaXFlwyzSHPGnma3zWL86aqyliC/lcX+Huth6TCuxDZ1i/g5khRPR44uk6bZyTezjZlkXHfC90mU2QJGc/vEIH/1zlOxoeUoI40OG/zeQW3/6tKf/hsz7ZZEJWwLmn7LaUOx90SGYHzU/3ZF7Z8SGh58Fa22PHr5PRyD7ktJAEaTqnFapiWRe1xjlvdqY79qstSxECr9eXaIVhhCd+qpY2Ticke4XEQqdj028tYSnb9+1uWyJ+RCo39xoq+/5fO8biX9xQObphWkIg2ODRvVG0nRaC3vt2rtu9YUNmSloIfGqggWNjUTlbpcN7TCZQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=ac3c.607d952b.k2104; bh=0jJdHA9EN1sZ/ywWw7Vy4ew6WwwdZM1pBziL/KfpLGc=; b=UzGLv3+I4VgHuV01IHw9uTYtg+WbOZzzh70e4+tJoDOTlWGApdp7UDPZoXsAUiYptteg2KFia2ic54DEqbruNJBU4C96VT/EMGeiLYxPMjebCkti3MzGcJISv2tFjTzRZal3kyoiqrE6lOpmAbtnAMKEUF0Lw2PglPrceWDY/D42XmS557ghKBopujpufWuFoyn3qz/9l91X6PHIKemY34v59aswjLNt6vDMjEGRCEY2yvi8hb1ZvoRkOFu5QCb9cSobNbe/bJFhI9/gtR1OUBbpWLNW9RxV0h+xU7saPsdLkWqAROgFvIPVsCuzRKU/piloREbnXbZlAmjNmHQrDg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 19 Apr 2021 14:35:23 -0000 Received: by ary.qy (Postfix, from userid 501) id A259773A7224; Mon, 19 Apr 2021 10:35:22 -0400 (EDT) Date: 19 Apr 2021 10:35:22 -0400 Message-Id: <20210419143522.A259773A7224@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 19 Apr 2021 14:35:45 -0000 It appears that John C Klensin said: >The issue that dates, as specified in RFC5322, have poor >internationalization/localization properties. Although, as you >more or less point out, if one can parse them, one can convert >to local formats and convert back -- that is about whether it is >important to make a change, not about whether the format is >inconvenient. It is my impression that most MUAs parse the date header and redisplay it in a local format. Even Alpine, which has a pretty minimal user interface, does that. I also see that a lot of mail systems seem already to do what I suggested, use a minimal version of the date DD Mon YYYY HH:M:SS +0000 If everyone's reparsing the dates anyway, it doesn't much matter what the internal date format is, so I think it makes sense to recommend the simplest one consistent with the current spec. R's, John From nobody Mon Apr 19 07:39:51 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 A2BE83A33E9 for ; Mon, 19 Apr 2021 07:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 TG_yPTHTCkCs for ; Mon, 19 Apr 2021 07:39:45 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 E2D163A33E2 for ; Mon, 19 Apr 2021 07:39:44 -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 E7952362754 for ; Mon, 19 Apr 2021 14:39:42 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-16-47.trex.outbound.svc.cluster.local [100.96.16.47]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2FEF1363079 for ; Mon, 19 Apr 2021 14:39:41 +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.47 (trex/6.1.1); Mon, 19 Apr 2021 14:39:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shade-Obese: 6a0fbaef68fb284a_1618843182550_3208158080 X-MC-Loop-Signature: 1618843182550:1058740795 X-MC-Ingress-Time: 1618843182549 Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 39E47318C203 for ; Mon, 19 Apr 2021 14:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1618843179; bh=yYLqGiU23rRzV1jV+7Nk23yvj9s7ZXgULQk3/g69pKE=; h=Reply-To:To:From:Subject:Date; b=KXR/2W72bIyHbD+Bxzi/tn4IqIFTOGi3tUGdLjNiE3yWPjHk5WavMZpgF2b0VF4rh 1uZIy4yN4vmcElcTvY1jzRSB9g01/Q4L4YutPuE8qo7jqtaQHp/9mZWOazfKmZebag o+VHXd6PPKS0zyK7APq0NK++MuDZVhTiVHO9/p5p+s40XcjJXGXh3T2UPuL5gABoMa /ahPFQZd2noV8rABi4oVgmRxXiQdMd9Si4kEva7oNruOBfMJsiNj3yXOZ0FZaCM5Wx l+5pEwLeFMmza03bn9hB9m9UiJYHMGK31qLbaLPVXGq3xFV/YXTxo+KlMFDrcXPFW9 vJd5FJf35cXEg== Reply-To: dcrocker@bbiw.net To: "emailcore@ietf.org" From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> Date: Mon, 19 Apr 2021 07:39:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Date/Time considered confusing 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, 19 Apr 2021 14:39:51 -0000 An essential bit of instruction, for the earliest days of interoperability, is the difference between canonical (protocol-based) representation, versus the creating local user, and possibly versus end-receiving user display. For date/time, this maps to 'global time', local time for creator, local time for viewer and presentation style for viewer. As was common during the 70s (and quite a bit since then), RFC 733 sought to juggle all of these (except local time of viewer) into a single representation. As noted, being able to display the string 'directly' can aid debugging. This drove quite a bit of the protocol design then (and quite a bit since.) The benefit of using a human-comfortable, simple text representation has been demonstrably /very/ helpful for the adoption and debugging of Internet protocols. Requirements for special, protocol-aware translation software, in order to meaningfully display assorted protocol information, can be a significant barrier to adoption and use. For date/time protocol use, the basic choice is whether to have the protocol-based information encode local time, indicating the offset or zone from 'global' time, or on 'global' time, indicating offset or zone for the creator's location. In either case, offset/zone is essential, for mapping between author's local time and global time. An obvious issue for the choice is what will be the easiest and most accurate to work from, for the protocol (canonical) representation. Historically (and possibly still) a challenge for some systems has been that they don't know their offset/zone. The best they can give is whatever date/time is set manually for their system. Whether a protocol should support use by such systems is obviously an important design consideration. The challenge is to avoid being cavalier in that choice. The mere fact that a protocol or format was designed a long time ago does not mean it needs to be replaced. And displacing a specification that has been in global use for 45 years ought to set a very high bar and demand quite a bit of clear and compelling basis for replacing it. In terms of emailcore, perhaps I have missed the clear and compelling statement of need, that fits within the charter, for pursuing email date/time format changes, within the context of this working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Apr 19 08:11: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 6C0F83A34DC for ; Mon, 19 Apr 2021 08:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 W_Ah2ndCmdlN for ; Mon, 19 Apr 2021 08:11:20 -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 528A13A358E for ; Mon, 19 Apr 2021 08:11:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY1QTU2ZXS00CL69@mauve.mrochek.com> for emailcore@ietf.org; Mon, 19 Apr 2021 08:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1618844787; bh=HQ/l9C17T9pHwqSinzMSEGQ2jkLht8xcsNtUnWpej1o=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=DQGMFvrzpzOC37MPkrODYOqsE/LpNi6NPMf5ojMYzgu3YJyZlPded8Y/B4swpumNT qoDmtquRxAWYHN5QcMUD7ZY8yaLM0mk/e2Tx0zpIUCFl+y0RGE8fTzs/RdnP9jwmbB MFgt4IdWKLzgGjRKX/FRQ4f8VBeTDBpuRVO4pisY= 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 <01RY1PSYCKU80085YQ@mauve.mrochek.com>; Mon, 19 Apr 2021 08:06:24 -0700 (PDT) Cc: emailcore@ietf.org, john-ietf@jck.com Message-id: <01RY1QTS5WJE0085YQ@mauve.mrochek.com> Date: Mon, 19 Apr 2021 07:38:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 19 Apr 2021 10:35:22 -0400" <20210419143522.A259773A7224@ary.qy> References: <20210419143522.A259773A7224@ary.qy> To: John Levine Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 19 Apr 2021 15:11:24 -0000 > It appears that John C Klensin said: > >The issue that dates, as specified in RFC5322, have poor > >internationalization/localization properties. Although, as you > >more or less point out, if one can parse them, one can convert > >to local formats and convert back -- that is about whether it is > >important to make a change, not about whether the format is > >inconvenient. > It is my impression that most MUAs parse the date header and redisplay it > in a local format. Even Alpine, which has a pretty minimal user interface, > does that. I also see that a lot of mail systems seem already to do what > I suggested, use a minimal version of the date DD Mon YYYY HH:M:SS +0000 > If everyone's reparsing the dates anyway, it doesn't much matter what the > internal date format is, so I think it makes sense to recommend the simplest > one consistent with the current spec. Agreed. And this needs to be done in the AS document, for several reasons: (1) It's what applicability statements are *for*. (2) The idea of moving stuff like the leading weekday to the obsolete syntax may seem attractive, but would in fact be an interoperability disaster as new implementations appear that fail to accept obsolete syntax (no matter that the standard says they're supposed to) and the gazillion existing implementations fail to upgrade. This is an especially serious concern because right now the stuff in the obsolete syntax is for the most part something implementations *can* ignore and get away with it. A subsetting of the Date: field syntax, OTOH, is nothing of the sort. (3) The idea of putting an RFC 3339 timestamp in a comment is the very definition of a silly state generator. Although I admit it might be amusing - for some value of the word "amusing" - to see the effect of code written like this: time(¤ttime); // Use currenttime to generate the RFC 5322 date/time time(¤ttime); // Use currenttime to generate the RFC 3339 date/time on various implementations. Implementations that assume the content of the comment is a time zone make will also produce some interesting results. I will also note that historically parsing of comments in Date: fields has been a big source, if not the biggest source, of bugs. (The implementation that added the time zone offset specified by the comment and the one in the actual date-time specification was particularly problematic.) I also don't see what this buys us - even assuming we could get traction on putting this information in, do we then expect it to then be used preferentially? I'm sorry, but I don't see that happening, at least not on a timescale short enough to matter. (4) Absent this being a major, ongoing problem - and I've seen no evidence that it is or is becoming a major problem - makes anything other than AS text out of scope according to our current charter. Ned From nobody Mon Apr 19 08:16: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 938453A350E for ; Mon, 19 Apr 2021 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 (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 6w4kvvlX0YDN for ; Mon, 19 Apr 2021 08:16:30 -0700 (PDT) Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (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 B41A33A34FE for ; Mon, 19 Apr 2021 08:16:29 -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 08708362DC2 for ; Mon, 19 Apr 2021 15:16:28 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-18-71.trex.outbound.svc.cluster.local [100.96.18.71]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 5BD75362DBE for ; Mon, 19 Apr 2021 15:16:25 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.18.71 (trex/6.1.1); Mon, 19 Apr 2021 15:16:27 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Glossy-Relation: 19a93dbb15f9a3b4_1618845387742_3726722976 X-MC-Loop-Signature: 1618845387742:3947097919 X-MC-Ingress-Time: 1618845387742 Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 6843832220C9 for ; Mon, 19 Apr 2021 15:16:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1618845383; bh=YzQ9+cHOjleuBLm7FZhVEXsPBI4L6yloKSwfBz+rWU4=; h=Reply-To:To:From:Subject:Date; b=Z61V0hlGHPI2w1bVRp5SolL60QMla6NK5XCDvmcu6Ym6WK7slNihRnjHGNJnyhexd Y8lKbTiQcfngjczDXDsBKhRJQSxDCs7vYKktSNtAVBOQ+98M/bifzlbDvOmtE4hSD9 TLrpas3/P/jskEeBshBA8W1VvyflA7LAOoF+EcQpKnXx9281rRNOnrLEbUmIebyC9P 2gLH+fzYhGKfYoB3CX+U+yuHYCgYUCxYttu0WxzWHasoa8RqxKgo2kK5j7/r9GuzLU yoeryIbQMSbjXTqY22utTXenxb+JQQbxruL+cUF778lbO6v+w+V1UmFFF35rErmJ1M u4QBeE7EOgqCA== Reply-To: dcrocker@bbiw.net To: "emailcore@ietf.org" From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 19 Apr 2021 08:16:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [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: Mon, 19 Apr 2021 15:16:35 -0000 The idea of marking some existing constructs for future deprecation is intuitive and appealing. The experience of doing this at Internet scale? Not so much. Yet another demonstration of the difference between theory and practice. (cf, "X-"). When something has been marked for deprecation for 25 years but hasn't been deprecated, it might mean that the particular choices in assigning that status were wrong. More likely, it means the construct of an obsolescence sequence was wrong. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Apr 19 09:35: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 2A6A33A39D0 for ; Mon, 19 Apr 2021 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-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 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 LDw7dbE28170 for ; Mon, 19 Apr 2021 09:35:39 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id A6B9E3A39CB for ; Mon, 19 Apr 2021 09:35:32 -0700 (PDT) Received: (qmail 38629 invoked from network); 19 Apr 2021 16:35:29 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (40642dd6-a12d-11eb-8746-9bd1f0874900); Mon, 19 Apr 2021 09:35:29 -0700 To: emailcore@ietf.org References: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <2920a19b-294a-1e01-9d5b-d16168563fc4@linuxmagic.com> Date: Mon, 19 Apr 2021 09:35:29 -0700 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: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 40642dd6-a12d-11eb-8746-9bd1f0874900 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Emailcore] Date/Time considered confusing 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, 19 Apr 2021 16:35:44 -0000 +1 On 2021-04-19 7:39 a.m., Dave Crocker wrote: > The mere fact that a protocol or format was designed a long time ago > does not mean it needs to be replaced.  And displacing a specification > that has been in global use for 45 years ought to set a very high bar > and demand quite a bit of clear and compelling basis for replacing it. > > In terms of emailcore, perhaps I have missed the clear and compelling > statement of need, that fits within the charter, for pursuing email > date/time format changes, within the context of this working group. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Apr 19 09:55: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 E3AE43A3AB5 for ; Mon, 19 Apr 2021 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 lH0PBWh5x6Ri for ; Mon, 19 Apr 2021 09:55:44 -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 49D253A3AB2 for ; Mon, 19 Apr 2021 09:55:43 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTP id 471671605B; Mon, 19 Apr 2021 18:55:41 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id C4AF31080B; Mon, 19 Apr 2021 18:55:48 +0200 (CEST) Date: Mon, 19 Apr 2021 18:55:48 +0200 From: Steffen Nurpmeso To: "John Levine" Cc: emailcore@ietf.org, john-ietf@jck.com, Steffen Nurpmeso Message-ID: <20210419165548.Mi4N0%steffen@sdaoden.eu> In-Reply-To: <20210419143522.A259773A7224@ary.qy> References: <20210419143522.A259773A7224@ary.qy> Mail-Followup-To: "John Levine" , emailcore@ietf.org, john-ietf@jck.com, Steffen Nurpmeso User-Agent: s-nail v14.9.22-112-g04a36981bd 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] RFC 822 dates considered harmful ? 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, 19 Apr 2021 16:55:49 -0000 John Levine wrote in <20210419143522.A259773A7224@ary.qy>: |It appears that John C Klensin said: |>The issue that dates, as specified in RFC5322, have poor |>internationalization/localization properties. Although, as you |>more or less point out, if one can parse them, one can convert |>to local formats and convert back -- that is about whether it is |>important to make a change, not about whether the format is |>inconvenient. | |It is my impression that most MUAs parse the date header and redisplay it |in a local format. Even Alpine, which has a pretty minimal user interface, |does that. I also see that a lot of mail systems seem already to do what The even more minimal POSIX mailx also do this. (Apple, OpenBSD etc. do not since their Mail has never stepped beyond the very basic implementation.) The one i maintain does not dig obsolete zone names (as of 4.3), the NetBSD Mail variant even knows about those. (On the other hand NetBSD's version uses their sophisticated non-portable strptime() to parse the date as such, whereas we unroll the code on our own.) |I suggested, use a minimal version of the date DD Mon YYYY HH:M:SS +0000 | |If everyone's reparsing the dates anyway, it doesn't much matter what the |internal date format is, so I think it makes sense to recommend the \ |simplest |one consistent with the current spec. Day of week we simply skip (converting to time_t directly, whereas NetBSD Mail fills in a struct tm* and uses timegm(3), therefore verifying validity of wday, too). Anyhow, we all localtime(3). --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 Mon Apr 19 11:20:07 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 3639B3A3D8F for ; Mon, 19 Apr 2021 11:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=GLyVEOJG; dkim=pass (2048-bit key) header.d=taugh.com header.b=DGp+1FIk 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 RuToWuApvY-W for ; Mon, 19 Apr 2021 11:20:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC26B3A3D8A for ; Mon, 19 Apr 2021 11:19:59 -0700 (PDT) Received: (qmail 10166 invoked from network); 19 Apr 2021 18:19:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=27b3.607dc9cd.k2104; bh=K/jAj4ZD6tkSleDJZFaTVF6MwuSm+njNU1BJwTxMun4=; b=GLyVEOJGlWQuR+WpunI8dytl6dWGYhpTK/YUnnCh3PliZPgvJQW2w+I7wv+mkZ+ssqG8IDkXW451sLXsptD1bgph0xWpxZsbo61aCziT/pB9jM3SY7CVBC0k7R9b0kXgN19Q9gxnfzX2BRR1vxD2tvbXfmDialxv33Q36gYLiePz3CJO6CMqBtVxYrTy7RvYyHCU3D6gkW+BDo0JqNm69q9VoaFx0ThJvgjkd8UOgivreC2E0Wob5UsUttCbSga7e31OEbduwA318TQN6edeImUHhl4zBASLb6/bb9orELwF63D7Q8vpdiXyubXULHf4Clb7Sp6KpdoH4xjjfyMiJQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=27b3.607dc9cd.k2104; bh=K/jAj4ZD6tkSleDJZFaTVF6MwuSm+njNU1BJwTxMun4=; b=DGp+1FIkdaanUY+TR1dgaGDw3l7RXO9CUqNsZkaCn+OPape3EzgEc/k+EDjqOz6vX7dyDtYokZrhP7s045q4b48pAUZlkLmAjKincMJ62+iuAkVT6JU5k042DA9NlaKIZ7oIGxUf3FJaeeRaddruDk4f9Pgquq5KjOuw145B75ceg5q37i6IsEzdGoUBdYSlukVkFvVPdTML1eGCaJMA7+5zmFSjim0tH1KJB+3BoLBhVmZmS1SbTqk/ruTVXeVYm9mmwyrdHFj4+hdiw2nhWf6kdIOWbHOJy+H5+klKXmX2vxo55VJc28KqS6d5Tz6/qsofI6ZgM0KEDFDMY7XXaA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 19 Apr 2021 18:19:57 -0000 Received: by ary.qy (Postfix, from userid 501) id D14A273A9558; Mon, 19 Apr 2021 14:19:56 -0400 (EDT) Date: 19 Apr 2021 14:19:56 -0400 Message-Id: <20210419181956.D14A273A9558@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Date/Time considered confusing 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, 19 Apr 2021 18:20:05 -0000 It appears that Dave Crocker said: >In terms of emailcore, perhaps I have missed the clear and compelling >statement of need, that fits within the charter, for pursuing email >date/time format changes, within the context of this working group. How do you feel about Ned and my proposal to use a minimal profile of Date: in outgoing mail. I agree we have to keep accepting all of the date formats that RFC 5322 allows but we can perhaps shrink the surface for errors. I think on the modern Internet we can assume that anything that is going to add a Date header knows the correct time since if you can talk SMTP you can talk NTP and every phone and laptop I've seen in the past decade includes an NTP client. Remarkably few people know what time zone they are in which is why I would prefer to leave them out of date stamps. R's, John From nobody Mon Apr 19 11:52: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 32D993A3EFE for ; Mon, 19 Apr 2021 11:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[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, 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 XD8N3bJnSCoo for ; Mon, 19 Apr 2021 11:52:52 -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 16C0B3A3EF3 for ; Mon, 19 Apr 2021 11:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1618858362; bh=b0RqP/u96Cqlv5ccRx9RCXkNQZgJPm7EdY6Lg4NMHiE=; l=1310; h=To:References:From:Date:In-Reply-To; b=ASbFLqA8a+1nA00yxGXAxTJGJo8qvzTKMMJvf8k7zKdrg/0YLDbRO7ru1fKOdBvSS VPXlq84ohgeNXzNR5bY/Nu8T4ki9P+LuH7W6eagdfTk+QjbyPGDyZ0ENMOZXy9jn8V UCbIPMi3YrFZUaLxetk6TwZad7hker8hbytzBhwWRIpNtS9haCexP2poCZLoJ 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 00000000005DC028.00000000607DD17A.0000278C; Mon, 19 Apr 2021 20:52:42 +0200 To: John C Klensin , emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Mon, 19 Apr 2021 20:52:41 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 19 Apr 2021 18:52:57 -0000 On Mon 19/Apr/2021 16:10:47 +0200 John C Klensin wrote: > --On Sunday, 18 April, 2021 20:25 +0200 Alessandro Vesely wrote: >> On Wed 14/Apr/2021 18:12:49 +0200 John C Klensin wrote: > >>> (1) Ignore the issue and hope it goes away or, at least, does >>> not get worse. >> >> Which issue? > > The issue that dates, as specified in RFC5322, have poor > internationalization/localization properties. Although, as you > more or less point out, if one can parse them, one can convert > to local formats and convert back -- that is about whether it is > important to make a change, not about whether the format is > inconvenient. IMHO, RFC5322.Date has an excellent readability. I think all the people who can understand the meaning of "Date" can also understand the content of average header fields bearing than name. It is a formatted field. If we change format, we'd better change the name as well. We cannot recommend this: 日期: 2021年4月19日星期一10:10:47 -0400 because field names must be in English. Breaking compatibility for a half-baked internationalization attempt doesn't seem to be good. To publish an A/S to state that formatted fields should be parsed and their meaning rendered in a localized form wood look like an exercise of style. Best Ale -- From nobody Mon Apr 19 13:52:43 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 C2F4E3A43A8 for ; Mon, 19 Apr 2021 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 B9RfMKg9SHmv for ; Mon, 19 Apr 2021 13:52:36 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D5B3A43AB for ; Mon, 19 Apr 2021 13:52:36 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id A03B6498F; Mon, 19 Apr 2021 22:52:28 +0200 (CEST) Date: Mon, 19 Apr 2021 22:52:28 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210419205228.GA20991@hjp.at> References: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> <20210419181956.D14A273A9558@ary.qy> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20210419181956.D14A273A9558@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Date/Time considered confusing 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, 19 Apr 2021 20:52:42 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-04-19 14:19:56 -0400, John Levine wrote: > It appears that Dave Crocker said: > >In terms of emailcore, perhaps I have missed the clear and compelling=20 > >statement of need, that fits within the charter, for pursuing email=20 > >date/time format changes, within the context of this working group. >=20 > How do you feel about Ned and my proposal to use a minimal profile > of Date: in outgoing mail. I don't really see the advantage over the status quo. > I agree we have to keep accepting all of the date formats that RFC 5322 > allows but we can perhaps shrink the surface for errors. I don't think that it helps much. The day of week is competely redundant, but it's also impossible to get wrong and the receiver will almost certainly ignore it anyway. The time zone might be wrong, but if it is wrong, then the computer's idea of global time is probably also wrong, so using UTC doesn't help. And on the flip side, the time zone is at least sometimes useful, so I think we would need a genuine advantage for ditching it (I'm actually a bit irritated at senders which always use UTC (cloud-hosted MS Exchange?)). > I think on the modern Internet we can assume that anything that is > going to add a Date header knows the correct time since if you can > talk SMTP you can talk NTP and every phone and laptop I've seen in the > past decade includes an NTP client. Remarkably few people know what > time zone they are in which is why I would prefer to leave them out of > date stamps. That seems a bit contradictory: NTP distributes a global time, not local time. If you use NTP and get the timezone wrong, the time displayed by your computer (or phone) will be wrong. People tend to notice that. Before NTP was wide-spread people could set the wrong timezone, set the correct local time and never notice that anything was wrong (except maybe that time time would be wrong for a few weeks in spring until it magically fixed itself). Now that's pretty much impossible. (Of course some people will ignore that (just like they ignore the flashing 00:00 on their microwave), but given how much people rely on their computers and especially phones, I'd guess that most would pester their "personal IT-support" to fix it if they can't do it themselves.) hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmB97YcACgkQ8g5IURL+ KF305xAAlYUZQRxJUTbWvfxCCIMq+jSeu8C5bb6MAoNVDunQadnumWv1Z5MDWk9V Y4MiqXqwcdg7+hIGxJ2c6B0iCXfpbadJ0jYw4DX1XLtt8rvZHLI8huxBiNmR75Of g6HbYlzJzzOBLqL//5HV2iAoLvoq3OUeP1eBNwtHtY9ZpTwxOUSdVbEh1+lhuYxn wU0/N3qmU6hFzRyd3UuI5jjmjiup+yrUk7GfxQSdWxNdQNnPEZHAMVA5M1fTIrwb 3Mm2Bpa2XHBEN1P8Zo+NoJyD2NlNFdnjvbxpHti/vzto5zivFiNmYuQFqG/AGN/W 4ZoLALcOJN4gogQwHHXdlN23ySp0iAUv52DSW9jljA9n9nDQ0g4FmVRGE9SRWhVg 9sZzAa5MXULwRdmPkOQv0rjmTq9U2E95aKkrqFJumD+QgJ4axgFeqDkdznCBVuaa EXCDJZwRDMXxKcPv77hrJBbUDx/wW3/0cZ83nztyQUMhgZSa7Q/lWwhqBUpjgdIu khbMO4mI/lLAHtKA4xADCVnGQhDgy1xNGF8JUUZ8WTXdOjI0QYIkseZuPPnDIDOw hduc0/7dCJE9MwoxAlP7vnwg84R64T26HTAJSOEqhOGhFz+0qdXm1ZAIlWOFZxTR UjZHituACMqT87gqu0CThOEG5jMgECeMNV6T9pdZ1cixxjBHc1c= =O7Xd -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From nobody Mon Apr 19 14:35:10 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 EF47C3A452D for ; Mon, 19 Apr 2021 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 3d_xJWeCFZQt for ; Mon, 19 Apr 2021 14:35:04 -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 04B283A452A for ; Mon, 19 Apr 2021 14:35:03 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTP id 8AE6816056; Mon, 19 Apr 2021 23:35:00 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 4377A10817; Mon, 19 Apr 2021 23:35:08 +0200 (CEST) Date: Mon, 19 Apr 2021 23:35:08 +0200 From: Steffen Nurpmeso To: "Peter J. Holzer" Cc: emailcore@ietf.org, Steffen Nurpmeso Message-ID: <20210419213508._4ekh%steffen@sdaoden.eu> In-Reply-To: <20210419205228.GA20991@hjp.at> References: <7d46469d-1ca8-9c3e-8f53-7f4d05454a21@dcrocker.net> <20210419181956.D14A273A9558@ary.qy> <20210419205228.GA20991@hjp.at> Mail-Followup-To: "Peter J. Holzer" , emailcore@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.22-112-g04a36981bd 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] Date/Time considered confusing 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, 19 Apr 2021 21:35:09 -0000 Peter J. Holzer wrote in <20210419205228.GA20991@hjp.at>: |On 2021-04-19 14:19:56 -0400, John Levine wrote: |> It appears that Dave Crocker said: ... |> I think on the modern Internet we can assume that anything that is |> going to add a Date header knows the correct time since if you can |> talk SMTP you can talk NTP and every phone and laptop I've seen in the |> past decade includes an NTP client. Remarkably few people know what |> time zone they are in which is why I would prefer to leave them out of |> date stamps. | |That seems a bit contradictory: NTP distributes a global time, not local |time. If you use NTP and get the timezone wrong, the time displayed by As long as there is no reliable and gracefully accessible way to get at TAI all this discussion is a bit off in my opinion. What we would really need for computing would be CLOCK_TAI in the standard, and TAI available everywhere. UTC is a really great thing, for humans, but computers and software just have no interest in the sun. --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 Tue Apr 20 09:15: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 B6BD93A298D for ; Tue, 20 Apr 2021 09:15:52 -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 oxPBOlrJBQxQ for ; Tue, 20 Apr 2021 09:15:48 -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 2BF413A2988 for ; Tue, 20 Apr 2021 09:15:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 1B1FAE1CAD65; Tue, 20 Apr 2021 11:15:47 -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 IpLyvV9iyVlT; Tue, 20 Apr 2021 11:15:45 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 8B673E1CAD55; Tue, 20 Apr 2021 11:15:45 -0500 (CDT) From: Pete Resnick To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Tue, 20 Apr 2021 11:15:45 -0500 X-Mailer: MailMate (1.14r5795) Message-ID: In-Reply-To: References: 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: Tue, 20 Apr 2021 16:15:53 -0000 On 19 Apr 2021, at 10:16, Dave Crocker wrote: > The idea of marking some existing constructs for future deprecation is > intuitive and appealing. The experience of doing this at Internet > scale? Not so much. > > Yet another demonstration of the difference between theory and > practice. (cf, "X-"). > > When something has been marked for deprecation for 25 years but hasn't > been deprecated, it might mean that the particular choices in > assigning that status were wrong. > > More likely, it means the construct of an obsolescence sequence was > wrong. Luckily, none of 2822, 5322, nor 5322bis say that such constructs are "for future deprecation", and there was never any such implication AFAICT. They are "obsolete" only in the sense that they are (or at least ought to be) no longer produced and are out of date. They are defined because implementations must be able to appropriately parse extant messages in storage. Perhaps "obsolete" was not the best label, because it implies that they are no longer produced at all, and we don't actually know that for sure (and there's pretty good reason to believe that old implementations appear in the weirdest of places), but deprecation was never on the table. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Apr 20 09:20:57 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 2AB263A29B8 for ; Tue, 20 Apr 2021 09:20:56 -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 q8JgYoARU4p0 for ; Tue, 20 Apr 2021 09:20:50 -0700 (PDT) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 3FF093A29B5 for ; Tue, 20 Apr 2021 09:20:49 -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 B2006342180; Tue, 20 Apr 2021 16:20:48 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-98-55-74.trex.outbound.svc.cluster.local [100.98.55.74]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id AB37D34291B; Tue, 20 Apr 2021 16:20:45 +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.98.55.74 (trex/6.1.1); Tue, 20 Apr 2021 16:20:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Minister-Skirt: 49ba54874cbf95f1_1618935648262_1386349467 X-MC-Loop-Signature: 1618935648262:419395707 X-MC-Ingress-Time: 1618935648262 Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 7DE35204F9DA; Tue, 20 Apr 2021 16:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1618935644; bh=mUe1IJboRNlwogpzGQR2EJyoXwYB/vqw0XDcXpGn6Uw=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=bpn7StnUzBKL5/vg2McbLRWgaydTjHDGX3tPlyqeZcmf3OjsqZwiF3EVUJJrt5q2Z JVhZVMCIElV36x6NjSctuo2Yed9JEo8gdjXUhpy31x3r4Fe1pYJItvWqDthXw3TkOY cOg/jPs15lJNcsw8mZ05vV4YuMROqr8VJ917wicUFpg1eTs430MI64Antc8HyNRNJq H07SvtaApmvKeFXtPdJGHLwAEhCwmhmAqeIoeHk/CvYcLiVYXvuPnjmE31U+nVGBJ9 4WIuVqUeALC/bvXdF1zt0dbpIDRi7erVnJtOFfdMdGs1urQPkvuUwwvHCvXiwyppWv Tqde32AaMGBtA== Reply-To: dcrocker@bbiw.net To: Pete Resnick Cc: emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 20 Apr 2021 09:20:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.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: Tue, 20 Apr 2021 16:20:56 -0000 On 4/20/2021 9:15 AM, Pete Resnick wrote: > On 19 Apr 2021, at 10:16, Dave Crocker wrote: > Luckily, none of 2822, 5322, nor 5322bis say that such constructs are > "for future deprecation", and there was never any such implication > AFAICT. They are "obsolete" only in the sense that they are (or at least > ought to be) no longer produced and are out of date. They are defined > because implementations must be able to appropriately parse extant > messages in storage. Perhaps "obsolete" was not the best label, because > it implies that they are no longer produced at all, and we don't > actually know that for sure (and there's pretty good reason to believe > that old implementations appear in the weirdest of places), but > deprecation was never on the table. If receivers are expected to continue to parse something, then what is the claimed benefit of prohibiting their use in generation? None of the *22 specifications explain/justify this. d/ ps. If the construct reasonably must still be supported -- even if only by receivers -- the term 'obsolete' is, as noted, misleading. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Apr 20 09:32:02 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 709C33A2A12 for ; Tue, 20 Apr 2021 09:31:57 -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 YWS_4f6H4SHb for ; Tue, 20 Apr 2021 09:31:52 -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 D1A693A28FB for ; Tue, 20 Apr 2021 09:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id B4291E1CB4FD; Tue, 20 Apr 2021 11:31:51 -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 4lo5K2K4bVFh; Tue, 20 Apr 2021 11:31:49 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 105D8E1CB4EC; Tue, 20 Apr 2021 11:31:48 -0500 (CDT) From: Pete Resnick To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Tue, 20 Apr 2021 11:31:47 -0500 X-Mailer: MailMate (1.14r5795) Message-ID: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable 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, 20 Apr 2021 16:32:00 -0000 On 20 Apr 2021, at 11:20, Dave Crocker wrote: > On 4/20/2021 9:15 AM, Pete Resnick wrote: >> On 19 Apr 2021, at 10:16, Dave Crocker wrote: >> Luckily, none of 2822, 5322, nor 5322bis say that such constructs are = >> "for future deprecation", and there was never any such implication = >> AFAICT. They are "obsolete" only in the sense that they are (or at = >> least ought to be) no longer produced and are out of date. They are = >> defined because implementations must be able to appropriately parse = >> extant messages in storage. Perhaps "obsolete" was not the best = >> label, because it implies that they are no longer produced at all, = >> and we don't actually know that for sure (and there's pretty good = >> reason to believe that old implementations appear in the weirdest of = >> places), but deprecation was never on the table. > > If receivers are expected to continue to parse something, then what is = > the claimed benefit of prohibiting their use in generation? > > None of the *22 specifications explain/justify this. As it says in = https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html#s= ection-1.2.3-6 = : 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. > ps. If the construct reasonably must still be supported -- even if = > only by receivers -- the term 'obsolete' is, as noted, misleading. Yes, as I just said, perhaps the term is not ideal. But again, it = doesn't imply "deprecation", which was what your initial message seemed = to be about. pr -- = Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Apr 20 09:39:16 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 E5FDE3A0045 for ; Tue, 20 Apr 2021 09:39:14 -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_NONE=-0.0001, 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 evl-O9wpoEQf for ; Tue, 20 Apr 2021 09:39:10 -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 19C503A08A7 for ; Tue, 20 Apr 2021 09:39:00 -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 29AF53427E2; Tue, 20 Apr 2021 16:38:59 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-96-16-47.trex.outbound.svc.cluster.local [100.96.16.47]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 62498342923; Tue, 20 Apr 2021 16:38:57 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.47 (trex/6.1.1); Tue, 20 Apr 2021 16:38:59 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cure-Shrill: 66353c94378591cf_1618936738932_4236177998 X-MC-Loop-Signature: 1618936738932:1337444963 X-MC-Ingress-Time: 1618936738931 Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 272473169894; Tue, 20 Apr 2021 16:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1618936735; bh=FkNiWKMAA+VtvPtvHCRTyFU5YJenhQ37Vf4XYHAFWq0=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=B6rZqohjpwbrevOYp9wNBDMJWMecJrqZA+Zu9DeSnlkCZz0RI1YCX5dd8G7uo1+s5 8/edL/HA91cJg7evDR4q8NpY96lgyXYb+jTHGDJg2W8VrP2Cwe//qhTj3sPL/VcX3v T+f2YwNP/vs0uebWIZCPRjReyXh6V7hcqsQPDZg5igns5hgiRkzQMqPcudrAWGGKl2 FZjcZUf4+KhsejIhNwr6p9onlyrKbUo8SqbpjPmE6iyTLzWVoqw5iX6jNm/2MmcstB DN9XDDBDKcS3J0aDgNsAg5zrsEOeTb0prZK4xPGmFSM1Wl9CsiImUf/jayXiQOAU+p 3YSt6xiNrhdhQ== Reply-To: dcrocker@bbiw.net To: Pete Resnick Cc: emailcore@ietf.org References: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 20 Apr 2021 09:38:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> 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: Tue, 20 Apr 2021 16:39:15 -0000 On 4/20/2021 9:31 AM, Pete Resnick wrote: > As it says in > https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html#section-1.2.3-6 > : > >   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. Ahh. Thanks. I made the mistake of looking for text by using "obs-". sigh. Consider the irony of saying that receivers must support some construct and simultaneously claiming the constructs are "determined to be non-interoperable or to cause significant problems for recipients of messages". I'm pressing this point because we generally do a very bad job of talking about, specifying, and generally dealing with the realities about getting rid of bits of protocol usage, over time. We tend to have a reasonable goal, but seem erratic, or worse, at achieving it. I think we need vastly more care, description, specification, vetting, and monitoring of anything we think needs to be expunged over time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 21 09:32:03 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 913453A2E6B for ; Wed, 21 Apr 2021 09:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 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, 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 bZMvw4ZI-XM1 for ; Wed, 21 Apr 2021 09:31:53 -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 803A03A2E6A for ; Wed, 21 Apr 2021 09:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1619022706; bh=mG72kB6JmB2RLz22ez4/luMzApXO1XqkFVwytUjRomI=; l=1317; h=To:References:From:Date:In-Reply-To; b=A5spECZVXzViptykexBI1PIBzUj5Ke4QsytqC+UFA+pmZd8Px5ct7PQnYOWxjPiDg kql2kD6w3BTLkZXRd81h0er2x2U8rEQeVXy4CPmeTgpsf3/EYgpOnV6hQYu/nzoAVF GWjA7EJ6iI40QD0BcXZJV95kYUjPIeL7BlEeHasWB3ZA2abFD/epIeCOVW4Fs 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.0000000060805372.00000613; Wed, 21 Apr 2021 18:31:46 +0200 To: emailcore@ietf.org References: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> From: Alessandro Vesely Message-ID: <2f4c2a1f-20fb-7787-6077-db06eeb672dc@tana.it> Date: Wed, 21 Apr 2021 18:31:45 +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: 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, 21 Apr 2021 16:31:59 -0000 On Tue 20/Apr/2021 18:38:51 +0200 Dave Crocker wrote: > On 4/20/2021 9:31 AM, Pete Resnick wrote: >> As it says in >> https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html#section-1.2.3-6 >> : >> >>    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 Couldn't that be relaxed to "these elements MAY be interpreted by parsers"? It is already quite difficult to find correct implementations for the accepted grammar. Requiring that obs- be also implemented can push compliance so far that no programmers will want to tackle it. Perhaps, proposing a reachable target can improve parsers quality... >>    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. > > > I think we need vastly more care, description, specification, vetting, and > monitoring of anything we think needs to be expunged over time. +1 Best Ale -- From nobody Sat Apr 24 11:06:41 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 DB4BA3A195E for ; Sat, 24 Apr 2021 11:06:39 -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 rLZR5ta-UIJd for ; Sat, 24 Apr 2021 11:06:34 -0700 (PDT) Received: from olivedrab.birch.relay.mailchannels.net (olivedrab.birch.relay.mailchannels.net [23.83.209.135]) (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 86ED73A195D for ; Sat, 24 Apr 2021 11:06:33 -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 AD3DB701326; Sat, 24 Apr 2021 18:06:32 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-16-56.trex.outbound.svc.cluster.local [100.96.16.56]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id B56FC702517; Sat, 24 Apr 2021 18:06:29 +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.56 (trex/6.2.1); Sat, 24 Apr 2021 18:06:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Reign-Abaft: 7fda564214e05a02_1619287592484_1117700631 X-MC-Loop-Signature: 1619287592484:2599268667 X-MC-Ingress-Time: 1619287592484 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 9F84F31CE8B6; Sat, 24 Apr 2021 18:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1619287588; bh=Xn4SUjqagU1HtRKRcH8Z+xRpOjRSEbgN2GLRkOehs08=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=LA43CtG53bvQjGKkdsB9hWqECG0Pn8etafM1LCMm0j35AaRyWBO5pT9rkGWB3k0xH c6Bz6AVtDdlPwxFNuhE4JgOvX0E8uIM+HSIoB6H3dAbbJf+sH/cQmlQBfoEzIMky+5 VIEpSLcs+gpOzXgTXLaUQMA/BcEbcSBtrlVrFDUTKK9k7IH4oCnt6Kh59XA4hlmxIE NLxI7nvAppa8keZIurQu43swqhviBJqyMHv5Z+hZ15Rq5fqx7W/HploKrXwzOVIQWg K5eWskKqco2QupE8lpa1sSdvjzt4RmTN4GVGiKdhFk7GeO6pA6Vgd2gCSRJMI6J2K0 uyRtKUrs7HP7A== Reply-To: dcrocker@bbiw.net To: Alessandro Vesely , emailcore@ietf.org References: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> <2f4c2a1f-20fb-7787-6077-db06eeb672dc@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <546a1aea-9796-5512-5f48-165c76fc3357@dcrocker.net> Date: Sat, 24 Apr 2021 11:06:24 -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: <2f4c2a1f-20fb-7787-6077-db06eeb672dc@tana.it> 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: Sat, 24 Apr 2021 18:06:40 -0000 On 4/21/2021 9:31 AM, Alessandro Vesely wrote: > On Tue 20/Apr/2021 18:38:51 +0200 Dave Crocker wrote: >> On 4/20/2021 9:31 AM, Pete Resnick wrote: >>> As it says in >>> https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html#section-1.2.3-6 >>> >>>    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 > > Couldn't that be relaxed to "these elements MAY be interpreted by parsers"? > > It is already quite difficult to find correct implementations for the > accepted grammar.  Requiring that obs- be also implemented can push > compliance so far that no programmers will want to tackle it.  Perhaps, > proposing a reachable target can improve parsers quality... 1. RFC2822, RFC 5322 and the bis draft already contain a normative 'MUST' for support of the "obs-*" constructs. Which means that the /requirement/ for parsing and semantics support have been in place for (exactly) 20 years. There is no new burden, here. 2. Possibly moving to a SHOULD, but definitely moving to a MAY, actually would effectively deprecate the constructs. The question will be why that has not been ok for 20 years, but now is? (I'd expect the barrier for satisfying that answer to be especially high, given the wg charter.) 3. The fact that support has been required for 20 years fundamentally undermines the concept of 'obsolete'. Again: it was an entirely reasonable idea. The fact of continued requirement demonstrates a failed semantic. It probably also represents a failed idea. If it is still required for parsers then it is still being generated. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 24 12:03: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 7694B3A1B38 for ; Sat, 24 Apr 2021 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=fjIYlYyn; dkim=pass (2048-bit key) header.d=taugh.com header.b=AVOjzvvz 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 XJxI7jrKUl3f for ; Sat, 24 Apr 2021 12:03:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD493A1B12 for ; Sat, 24 Apr 2021 12:03:34 -0700 (PDT) Received: (qmail 49279 invoked from network); 24 Apr 2021 19:03:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c07d.60846b82.k2104; bh=lihMl2izEurOr6mR84oP25BK5r8kpCgeazEwdziOIfc=; b=fjIYlYynMxvDcrIQaHuNUpQKYEffDfMYoREdA8zTyorAOLfAanNLGAnO828BrFMznxn26VkmEC+Cf4s+QZ5JLRJe94dIQiP4XFksSZ9fBo0W02LbaXNaFNcwqmfT7jTXL+hTuUBEzDu+z5lUaJkXnX5py4/XCgqsIIdFct6W33mJH9/UGX2NA61B3XnMd+st6y+hbfOk/WWYf6OXt1+11q4B9YWuxt5z29u3zG4a8OOWk9Pfc40IH8NGrFPlxAnR9WCoFEKl/AvKWk9NTxSA4nP8FuwDRgIpcpbxeBsTP0vS9n7C62mcUunI20dmIf10P90YlVomB8EJefl6KsA0FA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c07d.60846b82.k2104; bh=lihMl2izEurOr6mR84oP25BK5r8kpCgeazEwdziOIfc=; b=AVOjzvvzNOS6fM3ieZ55QtRCbi9xhJWIT2T8Jn/8wQKAy3JIWMWNRkwqXeDY2uZ8H5WdKgJhN1qCb5dzx9CzziOhlYeE/tu4/sWBXEWrWdEUU5d2ijJbJKQBNjYzwLi2TWUVoqQ/kVXj2EMaR6ZzVPaspK2zuEGOIJlhWvDWXZTwampf0D2F3CZnCKZmnhePLogqtnKcxNyiYj3XpVKE37fR058zYecMt/k9XyYaldhY/9iOBJmW3cHGGQ/mandaeWG5e+Wg2l35IBtqhfxlMhGt2hAtcJXkWe6mjZF4S+hn2HijbrHLCSuYZri5Zzus+xk32HAdHFkgyyuIsjr6mg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Apr 2021 19:03:30 -0000 Received: by ary.qy (Postfix, from userid 501) id B796F73FF998; Sat, 24 Apr 2021 15:03:29 -0400 (EDT) Date: 24 Apr 2021 15:03:29 -0400 Message-Id: <20210424190329.B796F73FF998@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <546a1aea-9796-5512-5f48-165c76fc3357@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] '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: Sat, 24 Apr 2021 19:03:46 -0000 It appears that Dave Crocker said: >2. Possibly moving to a SHOULD, but definitely moving to a MAY, actually >would effectively deprecate the constructs. The question will be why >that has not been ok for 20 years, but now is? (I'd expect the barrier >for satisfying that answer to be especially high, given the wg charter.) Seems to me it depends on how much mail still uses them. I can't recall the last time I saw a route in an address, or a space before the colon in a header in non-spambot mail. Perhaps there are some archives of mail we could grep through. R's, John From nobody Sat Apr 24 13:09:59 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 0E44A3A1D72 for ; Sat, 24 Apr 2021 13:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gz25RtEZgNGW for ; Sat, 24 Apr 2021 13:09:52 -0700 (PDT) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595C73A1D70 for ; Sat, 24 Apr 2021 13:09:51 -0700 (PDT) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 752C649F3; Sat, 24 Apr 2021 22:09:49 +0200 (CEST) Date: Sat, 24 Apr 2021 22:09:49 +0200 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210424200949.GA8036@hjp.at> References: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> <2f4c2a1f-20fb-7787-6077-db06eeb672dc@tana.it> <546a1aea-9796-5512-5f48-165c76fc3357@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <546a1aea-9796-5512-5f48-165c76fc3357@dcrocker.net> User-Agent: Mutt/1.10.1 (2018-07-13) 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: Sat, 24 Apr 2021 20:09:57 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-04-24 11:06:24 -0700, Dave Crocker wrote: > On 4/21/2021 9:31 AM, Alessandro Vesely wrote: > > Couldn't that be relaxed to "these elements MAY be interpreted by parse= rs"? > >=20 > > It is already quite difficult to find correct implementations for the > > accepted grammar.=A0 Requiring that obs- be also implemented can push > > compliance so far that no programmers will want to tackle it.=A0 Perhap= s, > > proposing a reachable target can improve parsers quality... >=20 >=20 > 1. RFC2822, RFC 5322 and the bis draft already contain a normative 'MUST' > for support of the "obs-*" constructs. Which means that the /requirement/ > for parsing and semantics support have been in place for (exactly) 20 > years. There is no new burden, here. >=20 > 2. Possibly moving to a SHOULD, but definitely moving to a MAY, actually > would effectively deprecate the constructs. The question will be why that > has not been ok for 20 years, but now is? (I'd expect the barrier for > satisfying that answer to be especially high, given the wg charter.) Well, for one, RFC 5322 was published in 2008, so nobody has checked whether it was or wasn't ok for 13 years. It has now been a standards violation to generate messages with these obsolete forms for 20 years. One could argue that after 20 years programs which still haven't been updated are so rare that we don't have to bother.=20 I don't know wether that's true. I would certainly want to have access to a much larger and more diverse corpus of messages than I have to answer that question. I also don't remember whether we had any evidence that these forms were still in use in 2008. > 3. The fact that support has been required for 20 years fundamentally > undermines the concept of 'obsolete'. Yes. If you call something "obsolete" you should plan to remove it eventually (typically in the next revision or the one after that). > If it is still required for parsers then it is still being generated. That's a non-sequitur. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmCEewgACgkQ8g5IURL+ KF3kdg//SWzzGVVlNluCmWdau6zETEkUgT89bgVVV1l0iec6eLG4Dcbm66Z2XLlO RYylHu/na9V/9HaPcSX0GNYVjwdX1XtwqIgoOpLpCif1pCmHvUTyqOGIgRZ//Arj sGLTh3+JpZx5La6GiJ0fbni5q1LtYxrc1OHCCvYr28CwsUUFEHA7e11hsAOipsju iabA0/BuMfMrJXwRb28pvrUe6otT6ArwMh7PdOMLnVn4fKW3MNoHcSnZQs4UDSvt rxvlX/txFdt6/FbsyWr4VSU3ywrjSRDa7jRxoU8ZJviK6rdOunjgt1sJgqAHp2p5 WoqFpq9dSJb0vEEeTezW/Zyogj4fanFGlrk+Ml/hUHduBiU3/pfHxNnfwjdmm3gv rf3TBxF4qTjQCSApJQtQ+ttINr5/mMPJKtcbOCgiXDghhkyunam8oofl3f5i8Pb0 Fny+6hzcaNPSR+w6g7+9fH+km+tl+ukd9eQ23djCrDLunCSzO4/E+XG8ekkePZfx G4wTvFYbQQO8Ag6l7OO0Mq9oh1f2Zc1HDG+7ux0gYiB0smLpbEokKDkWVLHxrYxF FdsWSNjCl+ivXRH/wnyvAHwgzlzwUIKt4sWYGy3GcDLjhHhfNuTqMhVoWD9P5zEF 3hqSRFWkb5JpMCUkEMEZhp5rblpv+njLiEY+ghCfilMfCzVIfXg= =xrE2 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From nobody Sat Apr 24 13:28: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 B25103A1E09 for ; Sat, 24 Apr 2021 13:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 XJcL8DrhqQPZ for ; Sat, 24 Apr 2021 13:28:44 -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 54EDB3A1E05 for ; Sat, 24 Apr 2021 13:28:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 07B57E290209; Sat, 24 Apr 2021 15:28:43 -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 NQg_5pLihp4p; Sat, 24 Apr 2021 15:28:41 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 9EDF9E2901F8; Sat, 24 Apr 2021 15:28:40 -0500 (CDT) From: Pete Resnick To: John Levine Cc: emailcore@ietf.org, dcrocker@bbiw.net Date: Sat, 24 Apr 2021 15:28:38 -0500 X-Mailer: MailMate (1.14r5795) Message-ID: In-Reply-To: <20210424190329.B796F73FF998@ary.qy> References: <20210424190329.B796F73FF998@ary.qy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5D3FD581-117D-4DA2-AA65-271BFD7A232B_=" 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: Sat, 24 Apr 2021 20:28:49 -0000 --=_MailMate_5D3FD581-117D-4DA2-AA65-271BFD7A232B_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 24 Apr 2021, at 14:03, John Levine wrote: > On 24 Apr 2021, at 13:06, Dave Crocker wrote: > >> On 4/21/2021 9:31 AM, Alessandro Vesely wrote: >>> >>> It is already quite difficult to find correct implementations for >>> the accepted grammar. On what obs- syntax are implementations failing? >>> Requiring that obs- be also implemented can push compliance so far >>> that no programmers will want to tackle it.  Perhaps, proposing a >>> reachable target can improve parsers quality... I don't understand this bit: If we change the document to say that it's not required, that would cause people to implement things they haven't already? >> 3. The fact that support has been required for 20 years fundamentally >> undermines the concept of 'obsolete'. >> >> Again: it was an entirely reasonable idea. The fact of continued >> requirement demonstrates a failed semantic. It probably also >> represents a failed idea. If it is still required for parsers then >> it is still being generated. That doesn't follow: As I said in my earlier messages, one of the motivations for specifying the old constructs and expressing the need to parse them was extant mail stores, not simply that they are still being generated. For example, in the ietf@ietf.org list archive, there are messages from 1992 that still use the 3-letter time zones which appear in the obs-zone construct and 2-digit years that appear in the obs-year construct. My IMAP client (MailMate) parses them fine and sorts the messages properly. > I can't recall the last time I saw a route in an address... Found some of those from 1992 in the same mailbox. My IMAP client handles those fine (though I'm not sure what a server receiving one of them will do; probably ignore the route per 5321). > ...or a space before the colon in a header in non-spambot mail. Still on the lookout for one of those. > Perhaps there are some archives of mail we could grep through. I'm sure we have lots more. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_5D3FD581-117D-4DA2-AA65-271BFD7A232B_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 24 Apr 2021, at 14:03, John Levine wrote:

On 24 Apr 2021, at 13:06, Dave Crocker wrote:

On 4/21/2021 9:31 AM, Alessandro Vesely wrote:

It is already quite difficult to find correct implementat= ions for the accepted grammar.

On what obs- syntax are implementations failing?

Requiring that obs- be also implemented can push complian= ce so far that no programmers will want to tackle it.=C2=A0 Perhaps, prop= osing a reachable target can improve parsers quality...

I don't understand this bit: If we change the document to= say that it's not required, that would cause people to implement things = they haven't already?

  1. The fact that support has been required for 20 years fundamentally un= dermines the concept of 'obsolete'.

Again: it was an entirely reasonable idea. The fact of = continued requirement demonstrates a failed semantic. It probably also r= epresents a failed idea. If it is still required for parsers then it is = still being generated.

That doesn't follow: As I said in my earlier messages, on= e of the motivations for specifying the old constructs and expressing the= need to parse them was extant mail stores, not simply that they are stil= l being generated. For example, in the ietf@ietf.org list archive, there are messages= from 1992 that still use the 3-letter time zones which appear in the obs= -zone construct and 2-digit years that appear in the obs-year construct. = My IMAP client (MailMate) parses them fine and sorts the messages properl= y.

I can't recall the last time I saw a route in an address.= =2E.

Found some of those from 1992 in the same mailbox. My IMA= P client handles those fine (though I'm not sure what a server receiving = one of them will do; probably ignore the route per 5321).

...or a space before the colon in a header in non-spambot= mail.

Still on the lookout for one of those.

Perhaps there are some archives of mail we could grep thr= ough.

I'm sure we have lots more.

pr

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

--=_MailMate_5D3FD581-117D-4DA2-AA65-271BFD7A232B_=-- From nobody Sat Apr 24 13:47:41 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 C02DD3A1E96 for ; Sat, 24 Apr 2021 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 f2ZNsmEeAwhR for ; Sat, 24 Apr 2021 13:47:34 -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 014BC3A1E95 for ; Sat, 24 Apr 2021 13:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id BA1BBE290A0A; Sat, 24 Apr 2021 15:47:32 -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 09FZutT8zkNF; Sat, 24 Apr 2021 15:47:31 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 7089BE2909FE; Sat, 24 Apr 2021 15:47:31 -0500 (CDT) From: Pete Resnick To: "Peter J. Holzer" Cc: emailcore@ietf.org Date: Sat, 24 Apr 2021 15:47:29 -0500 X-Mailer: MailMate (1.14r5795) Message-ID: <8860E4A4-5DBB-4D70-A04D-C1808A35D7BA@episteme.net> In-Reply-To: <20210424200949.GA8036@hjp.at> References: <6D53F59E-D119-495D-9397-78E973F8F31E@episteme.net> <2f4c2a1f-20fb-7787-6077-db06eeb672dc@tana.it> <546a1aea-9796-5512-5f48-165c76fc3357@dcrocker.net> <20210424200949.GA8036@hjp.at> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_47D1A9D0-6E56-4E73-AAEC-AFF46B1118C6_=" 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: Sat, 24 Apr 2021 20:47:39 -0000 --=_MailMate_47D1A9D0-6E56-4E73-AAEC-AFF46B1118C6_= Content-Type: text/plain; format=flowed; markup=markdown On 24 Apr 2021, at 15:09, Peter J. Holzer wrote: > One could argue that after 20 years > programs which still haven't been updated are so rare that we don't > have > to bother. As I replied in Dave's message: Existing message stores are also an issue. >> 3. The fact that support has been required for 20 years fundamentally >> undermines the concept of 'obsolete'. > > Yes. If you call something "obsolete" you should plan to remove it > eventually (typically in the next revision or the one after that). The fact that we chose "obsolete" to describe these may be unfortunate (perhaps we should have called it "accept-only") and perhaps it was born out of my (our?) thinking that we were in fact the protocol police back in my younger days, but it really doesn't change whether we choose to keep those constructs around or not. As an interesting example from section 4.1: | Note: The "period" (or "full stop") character (".") in obs- | phrase is not a form that was allowed in earlier versions of | this or any other specification. Period (nor any other | character from specials) was not allowed in phrase because it | introduced a parsing difficulty distinguishing between phrases | and portions of an addr-spec (see section 4.4). It appears | here because the period character is currently used in many | messages in the display-name portion of addresses, especially | for initials in names, and therefore must be interpreted | properly. The "." appearing in a phrase was not in the least "obsolete" in the true definition of the word; it was a newer existing practice that violated the previous standard for parsing messages. But it needed to be part of the "accept" syntax because we knew parsers were going to need to deal with it. I just can't get myself excited about worries that the terminology use in this case is wrong or misleading. Maybe it is. But (to create a Farberism) that's a lot of spilled milk over the bridge and now we've got to lie in it. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_47D1A9D0-6E56-4E73-AAEC-AFF46B1118C6_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 24 Apr 2021, at 15:09, Peter J. Holzer wrote:

One could argue that after 20 years
programs which still haven't been updated are so rare that we don't have<= br> to bother.

As I replied in Dave's message: Existing message stores a= re also an issue.

  1. The fact that support has been required for 20 years fundamentally

undermines the concept of 'obsolete'.

Yes. If you call something "obsolete" you should plan to = remove it
eventually (typically in the next revision or the one after that).

The fact that we chose "obsolete" to describe these may b= e unfortunate (perhaps we should have called it "accept-only") and perhap= s it was born out of my (our?) thinking that we were in fact the protocol= police back in my younger days, but it really doesn't change whether we = choose to keep those constructs around or not. As an interesting example = from section 4.1:

  |  Note: The "p=
eriod" (or "full stop") character (".") in obs-
  |  phrase is not a form that was allowed in earlier versions of
  |  this or any other specification.  Period (nor any other
  |  character from specials) was not allowed in phrase because it
  |  introduced a parsing difficulty distinguishing between phrases
  |  and portions of an addr-spec (see section 4.4).  It appears
  |  here because the period character is currently used in many
  |  messages in the display-name portion of addresses, especially
  |  for initials in names, and therefore must be interpreted
  |  properly.

The "." appearing in a phrase was not in the least "obsol= ete" in the true definition of the word; it was a newer existing practice= that violated the previous standard for parsing messages. But it needed = to be part of the "accept" syntax because we knew parsers were going to n= eed to deal with it.

I just can't get myself excited about worries that the te= rminology use in this case is wrong or misleading. Maybe it is. But (to c= reate a Farberism) that's a lot of spilled milk over the bridge and now w= e've got to lie in it.

pr

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

--=_MailMate_47D1A9D0-6E56-4E73-AAEC-AFF46B1118C6_=-- From nobody Sat Apr 24 18:11:30 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 3C4EB3A1742 for ; Sat, 24 Apr 2021 18:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS4N4N7tE6tR for ; Sat, 24 Apr 2021 18:11:24 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410117.outbound.protection.outlook.com [40.107.141.117]) (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 92A023A2831 for ; Sat, 24 Apr 2021 18:11:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VrzZuxIoiZq1UPI1EkWk52+6gCSt32VDyjVQxJ8csWRY3jalwzVwKc+gdxn65EV9Yyha+SCtQLQb48lSfAi126jCogJX/Z8B17axCTNzxOu/gYfi417EV4eiYQ5GWyC7CEjaRGr8LTpEEZBLOM5UsEJYGILebp81f1l5SHOg/IE0awo2okcR4pN2NVp7RihQ7LsHUKNcdg+hcUTEnwsUtXX2+r0KHlDrBfbfApU7xqvL7pIdJ+SUr5OpZuHZXEDQq7qrwRPGvxVMtdTK9U557ikxreZRkbQDshdSD4kbPumiojZYoRhY3rEzJpwY9w3NQSBACRRmjz5jmw2UcQhyYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U4s/1bLD+A6ZLfLxNiDPzfLVVmsL18elXhXuj/l/Nqw=; b=iF7Ph1SeBKDaXZkb0wRbTTbk67uS0iqclSe82pwlQB5humcS+jl2bHngQJRlne3y6uZWQYkuweW9NbdGlqTqZg/iAwfvJNdZyoA1YRYbBdA5K2hjLUSuDKVu+3b93V7xl4ueFe8zCntMydLTQ/9FBxXJ6/TCOV8yAkkpU/75DvP/YGO2D/YKvlIYa0eu+oRKfCkTJg1fJgt1aVOfdPgbmM3EXGIECQHcmmCo6T+7ZGZUOOjqDLBG6fuNCb4kYjXr6fRKhUQi/+JyTQOOn3UGPgcyWiVyKaan76CMlf9+/OG+SqAooakjVXsGh+vZKXwlfMQC3Vz2WBJbEsH6gC4Aow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U4s/1bLD+A6ZLfLxNiDPzfLVVmsL18elXhXuj/l/Nqw=; b=nA5A1Jci3uFUsYCoYIZZ0wc2UUKYP5RsoCFbkwqWkgi1C4R3PPr1L464sm/F6wvK0O5usEJltDgUms/lbO/XHTkJsLiOINKsZxECiQkWAKyG09+KB5+sFeD/IwWw/fzklhE6ii+6jIO28wgLM9BsNglH4UM/XL/FmToKRweIfeM= Authentication-Results: bbiw.net; dkim=none (message not signed) header.d=none;bbiw.net; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB6461.jpnprd01.prod.outlook.com (2603:1096:400:7b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Sun, 25 Apr 2021 01:11:19 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.4065.025; Sun, 25 Apr 2021 01:11:19 +0000 To: Pete Resnick Cc: emailcore@ietf.org, dcrocker@bbiw.net References: <20210424190329.B796F73FF998@ary.qy> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Sun, 25 Apr 2021 10:11:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [125.205.106.154] X-ClientProxiedBy: TYWPR01CA0003.jpnprd01.prod.outlook.com (2603:1096:400:a9::8) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (125.205.106.154) by TYWPR01CA0003.jpnprd01.prod.outlook.com (2603:1096:400:a9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21 via Frontend Transport; Sun, 25 Apr 2021 01:11:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5a39f291-fe92-4832-54fb-08d907870894 X-MS-TrafficTypeDiagnostic: TYCPR01MB6461: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jN/AmoH2i8Wnmi8W2bpjR1fo7RSoCihqZB7FCuHS8F0yxicUi1bhZrv1Nnhabb/HK1szTYSGcPpIhbW5FUuxOagy28yBhI0gCKDh22ArlKLF0YdKCeJfr5TOz7ripMzKz8oeM1fI330mWb3zOcsvLDm3mLjXhr0FEbH3i8hjrNzdti7l2vwFCV8EqBlAd6WY50FTqhtZZ2FekhNF+Qqn4fecfE5jEE0rvOQz/ZHAuzLRA7cFhCzYCZw2S6hbAY8RSFWzbjdzqHOLiTS7q3c6JlT9xhq0YhSz5tj8xE7ziWjKFOsoriRQHgkwh2PiyIw76qC1NszqQ27OvTsJLUymoayRnqAuaGNNMlEQbfrI+aC+uIS2DbiTOFASx8OY3u2mPaaQi80g26VaYpo2381lmZ6kN1of+VMsudck1/dRt2hZqyIxkeva79kQ6/XXcf1Wv4foOvqCrqnw4ZIwwsZcK3d4/3vcbTcVRwtSZ3m/6wAIjBlMWtfNiFA6lLoO/4BVZxfe0xWC6VALTMa/FsjMtIw/PbaRDyVApnGLRVjOYsu0geJonYhJkKzzU0sKylRj2zkkOhNkq+kir+YQjjGmRq4YGV1kNCkIJ5jzkDCLlkRtikG1mmjNRkkaR0rmkCi5RL4UFKesgVZVOPPL5X+bhxmYhte0QektPbXDdQvR1iU5zU/eUlizK9r4F53rBE4qKH1Q5Wz4XKSG5/pjZeZr0dwTA0K+WIl+cnv/GljeIoE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(366004)(396003)(376002)(346002)(136003)(53546011)(16526019)(186003)(38350700002)(38100700002)(26005)(2616005)(956004)(66946007)(5660300002)(66556008)(66476007)(786003)(316002)(16576012)(6486002)(86362001)(8936002)(478600001)(8676002)(83380400001)(31686004)(2906002)(36916002)(52116002)(4326008)(6916009)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UEFibTEyWGZQRmJIdDYzcVNPTFJ0YU5OVnVxRHdwMUFSVHRKb05TMk5kcmwy?= =?utf-8?B?VjY4cEJ5WVBxK2xKSEt6Zk5Za2dUZ3Z6amwxeEVKaXlScEd1Y0tUeWgwdGpy?= =?utf-8?B?cHVteXMzaTlKN2pucU14eG1HQ245aDFKU05LQjBlejk3K21qaHM3blF3V2RB?= =?utf-8?B?VjJ0c0N4NFFSbjQ1NjdEMUZCaVg3RDZEVWx2amNHOTVrRzlZajZpNG9Ua2FG?= =?utf-8?B?QVRMQXNmZEZ2SW9qb0cwdEs4ekQ3V2hCZFdCTHZ6dWZtZndPcUNvc1luVXll?= =?utf-8?B?TmRxaEgvcGh2VmdrTUpPRDd1RHdHYko0LzUvQjJPUkJadmMwYnpxbjZONXNi?= =?utf-8?B?dzUvVk5kYUpMK0hGM29pZnpZRXhVVUlSdStMd0Z6RnhDclFCaEdxSEltY0Nv?= =?utf-8?B?SEhhUzU3Nk85cE1DUlVCdkxFQng4cUFIN2hsY2VZalVDUlZYN21nZEJZZlNi?= =?utf-8?B?LzE0RUd2aUVrV3NuTmptZmdGVU42TmZjOUlrNTNQWGxTV3B4cEoxWUk4T2t1?= =?utf-8?B?ZTNvZmlRbGNpcEVEaEh2UnhneTRObWEwcEZENWFIMURzWkJpMmN2Kzh6aExC?= =?utf-8?B?UFVIMGt1Si9pbjBGeWJ1RDA4TjRjd1JxaldmYjVaY1JiS2RYS0YyR1lJYytJ?= =?utf-8?B?aHNUSjgzaUpTTEZuUnpXMERHbjBWSGRrRDdVUHFRVlBOK2MxaVF4TkZCK0J2?= =?utf-8?B?UTZLUnhKK3kvVzFsSk1QMzg4VEhrZE1IcUpiMFlpdm5qUFdYMTQ4cUc3VTZK?= =?utf-8?B?Y0ZBa1Rzc21jMWJQVEREaWlrcE9LSWtQNEwzZ0NtWFl6bDIvL25nbTJnL0RJ?= =?utf-8?B?MitvemdVT1BxQzFIRVlpMEhxOHRMYWRmUmk4Wm0reEpwZHhvTFJ5MU0zNWFa?= =?utf-8?B?NzR6clBRQWk5ZjFjVWpEUGlIL2d6eUVPOHBFVzVnRUtUUEpjbTRxOVd1bG15?= =?utf-8?B?SFNhcHljc1Q2WVNDRTNnQi8ySTlrbjF1eEl5bnFCaWthdXBScUhWdTMvTUtS?= =?utf-8?B?anV5aXR6V0p1d2J2UG9SbW9VekJMeFhUWEZnbW9sbld2T1BrTWU0RGluT3FS?= =?utf-8?B?dkF0ZlE5ZmpjMUFuMVFyNUZrZk52NUNLV0hlUndxdmpDWGlsWUpvQjBRU0dp?= =?utf-8?B?bjR2aEdndkJ3bEs2ZDRHTVpUNjVPTEFvYWdhTWFnTTNHWGtpUjNSUndQeVJm?= =?utf-8?B?MnFCNFNCaHlwU3QxdFBNNThTMS9IR1lFOXNTY3lCT1grOHRqbDJqU05jWExO?= =?utf-8?B?ZkVlUGxaNFlFQzRENTBlOG96RlNVRVpVTUVJZDc4U0dqamd4Vnd6NzlaNXlz?= =?utf-8?B?REo0VWlOWlpVZ1JnWjg2SUptWmh3eGw2RzgvMVpwbTNFTEc2TlAzYllKTGVp?= =?utf-8?B?anFSaDJZRUJXU1NFRmJJd3FQMnlwNGZzOXZvYk42YTQzQlVUeXhZQVhNT04w?= =?utf-8?B?U25UbGJpYWJiSXM0ZjJobm1IU3lJTmFnR1d2R29GOHBHT2dOd3FaWUxZTEUv?= =?utf-8?B?a0R1V2pNSU9oKzZaZS81WnVjN1hDNTEzRkJlcDErQ3M1Mmdjc250Zkg2OXZz?= =?utf-8?B?RmROR2M3S3p3c1FZalh1TTdLNUNOWUoxZ25TRzFOSGNib2Z5bklhOHdCVTRv?= =?utf-8?B?b3hWeHJZajk3b1g3QTVUNlFyYjlJd1FBc3phSzYycDIrcjdydDNqUmVlUUlh?= =?utf-8?B?YzMzazc5eS9OT09ocVM4dVNRbGR6ZENxdTIvZkFmK1JOQVdUTDZuNDhYWThx?= =?utf-8?Q?4KujxeITXWKPvh2wJY856mtYbpvbCJYDJ0vUxz+?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5a39f291-fe92-4832-54fb-08d907870894 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2021 01:11:19.6848 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HfzbLjfXgf2m9Ez4KLkpdukXM6yGb7EXshMfELyMO3Kbhtrp+pAsA8YqI36gFsEkV17SQBPkJ0NA1LRvajcQtQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6461 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: Sun, 25 Apr 2021 01:11:29 -0000 Hello Pete, others, On 2021-04-25 05:28, Pete Resnick wrote: >> On 24 Apr 2021, at 13:06, Dave Crocker wrote: >>> Again:  it was an entirely reasonable idea.  The fact of continued >>> requirement demonstrates a failed semantic.  It probably also >>> represents a failed idea.  If it is still required for parsers then >>> it is still being generated. > > That doesn't follow: As I said in my earlier messages, one of the > motivations for specifying the old constructs and expressing the need to > parse them was extant mail stores, not simply that they are still being > generated. For example, in the ietf@ietf.org list archive, there are > messages from 1992 that still use the 3-letter time zones which appear > in the obs-zone construct and 2-digit years that appear in the obs-year > construct. My IMAP client (MailMate) parses them fine and sorts the > messages properly. I'm not at all a mail expert, just a bystander, but could it possible that this means that MUAs and similar stuff MUST/SHOULD still be able to deal with the obs syntax, but MTAs and such don't? Just a wild guess, and even if true, wouldn't be sure it's worth making that distinction. Regards,   Martin. From nobody Sat Apr 24 18:44: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 2DB0B3A2926 for ; Sat, 24 Apr 2021 18:43:59 -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 ElE8FiccV-RH for ; Sat, 24 Apr 2021 18:43:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12103A2924 for ; Sat, 24 Apr 2021 18:43:54 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1laToK-000Mo5-TL; Sat, 24 Apr 2021 21:43:48 -0400 Date: Sat, 24 Apr 2021 21:43:42 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Pete Resnick cc: emailcore@ietf.org Message-ID: <693133E81003760D987E31C8@PSB> In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> 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: Sun, 25 Apr 2021 01:43:59 -0000 --On Sunday, April 25, 2021 10:11 +0900 "Martin J. D=C3=BCrst" wrote: >... > I'm not at all a mail expert, just a bystander, but could it > possible that this means that MUAs and similar stuff > MUST/SHOULD still be able to deal with the obs syntax, but > MTAs and such don't? Just a wild guess, and even if true, > wouldn't be sure it's worth making that distinction. Martin, Not really the issue here. First, although many things have happened (both in how the protocol specs are written in a real life), 5322 and its predecessors are traditionally entirely about "MUAs and similar stuff". The SMTP specification (and hence MTAs) treat obsolete or deprecated features somewhat differently. In particular, several bits in SMTP essentially prohibit choking on old syntax / features but recommend or require ignoring them. More important, in both specs (separately and in different ways), the general approach has been something like "don't send that but, because it used to be valid and/or required, you must continue to accept it". So everything is required to "deal with the obs syntax"; the prohibitions are just on generating/ sending it. Like Pete, I find it very hard to get excited about this. I also suspect that we would be far more likely to cause harm by trying to tinker with how outdated features or syntax are used than by leaving things alone. best, john From nobody Sat Apr 24 18:57:00 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 EAD243A18DB for ; Sat, 24 Apr 2021 18:56:58 -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_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 D5EUsaFvuNoU for ; Sat, 24 Apr 2021 18:56:53 -0700 (PDT) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (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 74F233A2985 for ; Sat, 24 Apr 2021 18:56:53 -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 B30531E2650; Sun, 25 Apr 2021 01:56:51 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-101-162-42.trex.outbound.svc.cluster.local [100.101.162.42]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 69CF51E25D4; Sun, 25 Apr 2021 01:56: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.101.162.42 (trex/6.2.1); Sun, 25 Apr 2021 01:56:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Name-Shade: 3e72afbb6f0c943a_1619315811413_2792347465 X-MC-Loop-Signature: 1619315811413:78239439 X-MC-Ingress-Time: 1619315811413 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 4140621EE123; Sun, 25 Apr 2021 01:56:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1619315808; bh=Hmvpyfau7xNZvP3hgy7Yh7aoeAlGh03vk7uQJCJH9h0=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=gitXD+KcJe2Ov2Q+XFnaLzcAvqCfCW7AXjwfE4NmBhnQJfp1M8PWPkwro9pK3KRPX 6Yn2STbU6kgNDqQmMSsNw2r6xn67UpwhvAUUErp2a5nRsGVMaELsKXyvC8gBib1Wrd sELty5ASyJIIUJTPZNzNYyr9hFNtp7xe2Tf5kTeXup6QS2P/tOv0MQIiPgg6ke2jOX SGn5ODNegG2l9+6ilvIG1IwZxr5xfMRtoxXlSC0Y9fK4IRv1y3wFaYzMh6zIZAb0VU BvWiayXOIWd4Rgx+82Y8oErnGavg+1qY8d5+4qbF+/CSNsha3rKNUVafD38HayiSx0 tbbpU6NZhDjbw== Reply-To: dcrocker@bbiw.net To: Pete Resnick , John Levine Cc: emailcore@ietf.org, dcrocker@bbiw.net References: <20210424190329.B796F73FF998@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> Date: Sat, 24 Apr 2021 18:56:41 -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: 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: Sun, 25 Apr 2021 01:56:59 -0000 On 4/24/2021 1:28 PM, Pete Resnick wrote: > 3. The fact that support has been required for 20 years > fundamentally undermines the concept of 'obsolete'. > > Again: it was an entirely reasonable idea. The fact of continued > requirement demonstrates a failed semantic. It probably also > represents a failed idea. If it is still required for parsers > then it is still being generated. > > That doesn't follow: As I said in my earlier messages, one of the > motivations for specifying the old constructs and expressing the need to > parse them was extant mail stores, not simply that they are still being > generated. For example, in the ietf@ietf.org list > archive, there are messages from 1992 that still use the 3-letter time > zones which appear in the obs-zone construct and 2-digit years that > appear in the obs-year construct. My IMAP client (MailMate) parses them > fine and sorts the messages properly. Merriam-Webster: Obsolete -- "no longer in use or no longer useful" The term is misapplied here. The term made sense when there was an actual expectation of removing the constructs. My recollection is that there was. Again, at the time, it wasn't a silly expectation. There cannot be a reasonable expectation of that, at this point. That makes the terminology wrong. The use of the term misleads the reader. In spite of the MUST, it encourages thinking that the constructs can be ignored, when they can't. The reality is that removing things from an installed base like the Internet has consistently been proving somewhere between incredibly difficult and impossible. Design work that works from that view stands a better change of being understood and implemented reasonably well. Language that purports there will be a future with removal invites confusion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 24 19:52:34 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 CF5233A2B3D for ; Sat, 24 Apr 2021 19:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50cqUiudqgDD for ; Sat, 24 Apr 2021 19:52:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AE33A2B3C for ; Sat, 24 Apr 2021 19:52:28 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1laUse-000MwP-Ul; Sat, 24 Apr 2021 22:52:20 -0400 Date: Sat, 24 Apr 2021 22:52:14 -0400 From: John C Klensin To: dcrocker@bbiw.net, Pete Resnick , John Levine , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= cc: emailcore@ietf.org Message-ID: <09BF2A137890DF17A459F62C@PSB> In-Reply-To: <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> 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: Sun, 25 Apr 2021 02:52:33 -0000 --On Saturday, April 24, 2021 18:56 -0700 Dave Crocker wrote: > On 4/24/2021 1:28 PM, Pete Resnick wrote: >> 3. The fact that support has been required for 20 >> years fundamentally undermines the concept of >> 'obsolete'. >> >> Again: it was an entirely reasonable idea. The fact >> of continued requirement demonstrates a failed >> semantic. It probably also represents a failed idea. >> If it is still required for parsers then it is still >> being generated. >> >> That doesn't follow: As I said in my earlier messages, one of >> the motivations for specifying the old constructs and >> expressing the need to parse them was extant mail stores, >> not simply that they are still being generated. For example, >> in the ietf@ietf.org list archive, >> there are messages from 1992 that still use the 3-letter time >> zones which appear in the obs-zone construct and 2-digit >> years that appear in the obs-year construct. My IMAP client >> (MailMate) parses them fine and sorts the messages properly. > > > Merriam-Webster: Obsolete -- "no longer in use or no > longer useful" > > > The term is misapplied here. The term made sense when there > was an > actual expectation of removing the constructs. My > recollection is that > there was. Again, at the time, it wasn't a silly expectation. > > There cannot be a reasonable expectation of that, at this > point. That > makes the terminology wrong. > > The use of the term misleads the reader. In spite of the MUST, > it encourages thinking that the constructs can be ignored, > when they can't. > > The reality is that removing things from an installed base > like the Internet has consistently been proving somewhere > between incredibly difficult and impossible. Design work that > works from that view stands a better change of being > understood and implemented reasonably well. Language that > purports there will be a future with removal invites confusion. Dave, Referring to my response to Martin, It seems to be that the spec is fairly clear that what is intended is "don't produce/ send this, but, for compatibility reasons, you need to continue to accept it". That seems to me to be both viable and pragmatic. It, in turn, seems to be consistent with the argument you are making above: as a particular example, I find the number of two-digit years we seem to be seeing in dates in recent years to be rather few although, like Pete, I am concerned enough about older mail archives that I think it would be unwise to pretend they were never valid. Given that, I don't understand what you are suggesting/ requesting. I trust it is not to go back to recommending the generation and use of, e.g., two-digit years. Do you have better terminology to suggest to replace the uses of "obsolete" and "obs-" while conveying the "don't send but must handle appropriately if received" idea and, if so, what would it be? I have also observed that you have several times made the argument that (at least as I have understood you) nothing should be considered in this WG unless their is compelling need for a change. While I continue to believe that a narrow interpretation of that criterion to cut off discussion is undesirable, because it is an argument you have made I'd like to understand how you think it applies in this case. Do you see a compelling need for change? Do you have evidence that presenting older syntax as "obsolete" or at part of "obs-XXX" has caused or continues to cause harm and/or confusion about the interpretation of the spec? thanks, john From nobody Mon Apr 26 03:54:45 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 E9D233A1A0B for ; Mon, 26 Apr 2021 03:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 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, 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 iFSOy0SLzimL for ; Mon, 26 Apr 2021 03:54:39 -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 015A13A1A09 for ; Mon, 26 Apr 2021 03:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1619434474; bh=KFCe/fT4DSccPEIQ5V9M4yhwXhZVcX0n3yM/3I+hRkw=; l=3610; h=To:Cc:References:From:Date:In-Reply-To; b=BQNT4NMBLmE7IOigyUFEH6TRGW2/XIuj7FbN5wrqpsr10FmoWKmRArtw3DxKaVZJV UPrygmYaHXeFo5fk6HIe30ik97HcDFjIkr1ALKmcGv1peLmHYAoO6ifPiIZnm0JhBs PDv0XqqVB8MJaWDj0CK0BNoYK9l/4HHK13bVompiubiAYzsAmi5xUmuN1KSM+ 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 00000000005DC053.0000000060869BEA.00004B22; Mon, 26 Apr 2021 12:54:34 +0200 To: John C Klensin , dcrocker@bbiw.net, Pete Resnick , John Levine , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Cc: emailcore@ietf.org References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> From: Alessandro Vesely Message-ID: Date: Mon, 26 Apr 2021 12:54:33 +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: <09BF2A137890DF17A459F62C@PSB> 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: Mon, 26 Apr 2021 10:54:44 -0000 On Sun 25/Apr/2021 04:52:14 +0200 John C Klensin wrote: > --On Saturday, April 24, 2021 18:56 -0700 Dave Crocker wrote: >> On 4/24/2021 1:28 PM, Pete Resnick wrote: >>> >>>> The fact of continued requirement demonstrates a failed semantic. It >>>> probably also represents a failed idea. If it is still required for >>>> parsers then it is still being generated. >>> >>> That doesn't follow: As I said in my earlier messages, one of the >>> motivations for specifying the old constructs and expressing the need to >>> parse them was extant mail stores, not simply that they are still being >>> generated. >> >> Merriam-Webster: Obsolete -- >> "no longer in use or no longer useful" >> >> The use of the term misleads the reader. In spite of the MUST, it >> encourages thinking that the constructs can be ignored, when they can't. >> >> The reality is that removing things from an installed base like the >> Internet has consistently been proving somewhere between incredibly >> difficult and impossible. Design work that works from that view stands a >> better change of being understood and implemented reasonably well. >> Language that purports there will be a future with removal invites >> confusion. > > It seems to be that the spec is fairly clear that what is intended is "don't > produce/ send this, but, for compatibility reasons, you need to continue to > accept it". That seems to me to be both viable and pragmatic. It, in turn, > seems to be consistent with the argument you are making above: as a > particular example, I find the number of two-digit years we seem to be > seeing in dates in recent years to be rather few although, like Pete, I am > concerned enough about older mail archives that I think it would be unwise > to pretend they were never valid. What is not so clear in the spec is the nature of those compatibility reasons. After Pete's examples, it is clear that there is a treasure trove of older mail archives. From such perspective, it doesn't sound so misleading to call their format "obsolete". It is an old format, no longer in use. Specifying the scope of obs- syntax might seem to weaken the MUST somewhat, for example like so: OLD: 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. NEW: 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. 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. However, old mail archives exist and are being being actively preserved. Parsers which may happen to be applied to such content MUST be able to interpret obs- elements, and hence be fully conformant to this specification. Best Ale -- From nobody Mon Apr 26 17:47:54 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 3D42B3A3825 for ; Mon, 26 Apr 2021 17:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 j1GG-TPrIfuK for ; Mon, 26 Apr 2021 17:47:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 739453A3823 for ; Mon, 26 Apr 2021 17:47:45 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 985905C0189 for ; Mon, 26 Apr 2021 20:47:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 26 Apr 2021 20:47:44 -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=AkBiVKmmX8cBcKicyvrGS5DHGNlnKCWr4NhJXgWmG Yc=; b=DI1dHtJLBDKaA+d70F9TUeVViHXBE0c6JjXtr51sD8kMGgTN/Z4PTrVRP bUaSXaFqqJYXpRzjU38dHDZMU9VwUKNNYWG+ojX6TAKo9uQ674aEfgVvYdGa8ePo X7HY/3owkJ6bgpwvrCeOdxPvy04P4LhIny6QxBCo8iqknfb5HKzUO9Fr2nzEs2rR F+6/8r+zR8G4x/s7/PKR6+qqs005qWh77qQs1vgr7NnEEsk4YE050YwRRGzFQOo7 EcBhIxQeZOHTX4jVJcCMquFCyrDGfrsdfe7uveAdjCSWdNDKnlGasRrpUXl4mdUX LkZCSOoJoUtwcZpqIQC6eCCofLjAA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdduledgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhuffvfhfkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehkeetudetgf effeehffeihfefffeiieduheffteelvddugeetudefieehgfegueenucfkphepvdefrddu 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 ; Mon, 26 Apr 2021 20:47:43 -0400 (EDT) From: Keith Moore To: emailcore@ietf.org References: Message-ID: Date: Mon, 26 Apr 2021 20:47:43 -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: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 27 Apr 2021 00:47:52 -0000 On 4/14/21 12:12 PM, John C Klensin wrote: > So, what is to be done? Possibilities include: > > (1) Ignore the issue and hope it goes away or, at least, does > not get worse. > > (2) Make some comments, probably in the A/S, about the > importance of understanding and following the specs in this area > (and hope someone notices) and probably warning about the > (additional) confusion and other consequences of not doing so.. If it helps to clarify the specification while keeping the format the same, by all means do so.   But that's not the same thing as ignoring the issue and hoping it will go away. > (3) Strongly encourage the use of an ISO 8601 date-time in a > comment after the required field, specifying that it should use > UTC ("Zulu") time only. Strongly disagree. The first lesson I learned in engineering school, in an engineering drawing class, was (as best I can recall the wording) "don't dimension the same point or line relative to more than one reference".   This lesson hit home because I had already made that mistake, in naively drawing up something to be built (a extra console for a planetarium).   The result was exquisitely crafted, and simply did not fit and could not be made to fit where it needed to fit.   I didn't realize the nature of my mistake until I actually started taking engineering classes.   Even though I've rarely used the drawing skills they painstakingly taught me, that hugely important lesson has stuck with me.   The generalization of this is "don't define the same thing in more than one way". Or there's the old saying "A person with one watch knows what time it is, a person with two watches is never certain." Don't duplicate the date-time in another format, not in a comment, not in another header field.   Have exactly one indication of the date that the message was sent. > (4) Change the syntax to what we would, I think, specify today, > defining the current syntax as an obsolete feature and perhaps > encouraging its inclusion in a comment. Strongly discourage this also.   There's nothing wrong with the current format. John Levine wrote: > How about if we pare down the definition of date-time to the minimum > > DD Mon YYYY HH:MM:SS +0000 > > and deprecate everything else including the optional day of week and > anything other than UTC. I would think this would be easier to explain > and easier for people to get correct. I could see discouraging the inclusion of the day-of-the-week (while still making it optional), as it's redundant at best and creates unnecessary errors at worst. I don't support getting rid of the timezone offset and normalizing everything to GMT, first because it's error-prone, and second because the timezone of the originator is actually useful to the recipient (even though, sadly, many mail readers try to hide such information). cketti wrote: > (5) Define new header fields, move current ones (as far as I can tell > this concerns "Date" and "Resent-Date") to obsolete syntax. Define a > transition period where MUAs should use both variants when creating > messages. After a cutoff date MUAs should only create messages using > the new header fields. No, please no.   In addition to having two sources of the same information (see above), it would accomplish nothing beyond adding additional complexity and failure states.  MUAs need to be able to read messages that are decades old because some people keep email around forever, and messages can be archived for historical purposes. If there's any benefit to simplifying the message format, it's in making new generators of email less likely to produce errors. It does nothing for email readers that generally need to be able to read things at least as old as RFC822 format (including pre-DNS email addresses) and maybe even RFC733 format (e.g. with " at " permitted between local-part and host). John Klensin again: > The issue that dates, as specified in RFC5322, have poor > internationalization/localization properties. If we wanted to fix this I'd say add the Olsen timezone as a comment following the GMT offset.   But there are too many (IMO broken) MUAs that already believe it is a Good Thing to hide the original timezone from the recipient (as well as much else that is valuable, like the sender's and recipients' email addresses).   And large numbers of hosts (think both mobile devices and IoT appliances) have a hard enough time getting their GMT offset right.   If the value is likely to be wrong, it's better to not include it at all than for the sending host (or worse, some intermediary) to guess. John Levine: > It is my impression that most MUAs parse the date header and redisplay it > in a local format. Even Alpine, which has a pretty minimal user interface, > does that. Just because "most" MUAs do something doesn't mean it's a good idea.  I'm fairly appalled at the behavior of some MUAs that insist on hiding useful information from recipients for the sake of... something.   Probably to make it fit on tiny screens or something. IMO the usefulness of email has been seriously degraded by several factors, one of which is that MUAs are much less functional than they used to be.   Let's not try to encourage more of that. Ned Freed: > (2) The idea of moving stuff like the leading weekday to the obsolete > syntax may seem attractive, but would in fact be an interoperability > disaster as new implementations appear that fail to accept obsolete > syntax (no matter that the standard says they're supposed to) and > the gazillion existing implementations fail to upgrade. > > This is an especially serious concern because right now the stuff > in the obsolete syntax is for the most part something implementations > *can* ignore and get away with it. A subsetting of the Date: > field syntax, OTOH, is nothing of the sort. There's something to be said for not making the specifications (especially the portion that mail readers have to pay attention to) any more complex than they already are, because this seems to have the effect of making implementations buggier. Dave Crocker: > The mere fact that a protocol or format was designed a long time ago > does not mean it needs to be replaced. And displacing a specification > that has been in global use for 45 years ought to set a very high bar > and demand quite a bit of clear and compelling basis for replacing it. +1 to both.   And IMO we should consider a specification that has been mostly stable for 45 years and continues to be in widespread use a huge success story, rather than an indication that something is wrong.   IETF needs more success stories like this. *** 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. Alessandro Vesely: > It is already quite difficult to find correct implementations for the > accepted grammar.  Requiring that obs- be also implemented can push > compliance so far that no programmers will want to tackle it.  > Perhaps, proposing a reachable target can improve parsers quality... Sounds like we need pointers to some reference implementations.   These days it's rare that anyone should need to implement a protocol entirely from the specifications. John Levine: > I can't recall the last time I saw a route in an address, or a space > before the colon in a header in non-spambot mail. I have, on multiple occasions within the past five years, been required to read copious volumes of email dating from the 1980s, and testify to its likely authenticity or lack thereof.   I can't recall the last occasion I saw such a message in current email, but it's still necessary to be able to read email dating from decades ago.   And this will become even more necessary in the future as more and more of our historical records exist only in digital form. (And just an aside, it's Really Unfortunate when the very program that the lawyers use to print out email, corrupts and/or hides the details needed to convince the court of a message's authenticity... like timezone information.   Then experts get to explain why the presented exhibits are wrong and should not be accepted as faithful copies of the originals.   Especially when archiving information, but also when reading archived information, it's vitally important to preserve the information in original format if at all possible.) Keith From nobody Mon Apr 26 18:51: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 9AE2E3A0CC0 for ; Mon, 26 Apr 2021 18:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mAA7SJYacBTo for ; Mon, 26 Apr 2021 18:51:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 D7E823A0CBD for ; Mon, 26 Apr 2021 18:51:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYC57HZ89C00H1E7@mauve.mrochek.com> for emailcore@ietf.org; Mon, 26 Apr 2021 18:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1619487975; bh=cOYf/+8fBWe42iQZlFUIbt5T/dy1ddSigkG5pdDufWw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=DEWaMFQtZBNq9pFS33ZonhhvI1ptifWRpEKjCR4wl4tTRpXMwXQs1/90MP+ab4sjX 5+gB5vfqiICuCPXZy4Z02HBCI+9pDdVyNLMqaywWIXPCSkSC5tpVUh8vDDbotNVOmI FVhGkWgfEOHPlyo43RW+dI0nAlCMPp/oTvbXp3bw= 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 <01RY7MJA8DGW0085YQ@mauve.mrochek.com>; Mon, 26 Apr 2021 18:46:13 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RYC57GMO7A0085YQ@mauve.mrochek.com> Date: Mon, 26 Apr 2021 18:23:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Apr 2021 20:47:43 -0400" References: To: Keith Moore Archived-At: Subject: Re: [Emailcore] RFC 822 dates considered harmful ? 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, 27 Apr 2021 01:51:24 -0000 > On 4/14/21 12:12 PM, John C Klensin wrote: > > So, what is to be done? Possibilities include: > > > > (1) Ignore the issue and hope it goes away or, at least, does > > not get worse. > > > > (2) Make some comments, probably in the A/S, about the > > importance of understanding and following the specs in this area > > (and hope someone notices) and probably warning about the > > (additional) confusion and other consequences of not doing so.. > If it helps to clarify the specification while keeping the format the > same, by all means do so.   But that's not the same thing as ignoring > the issue and hoping it will go away. +1. As I said previously, this is what an AS is there to do. > > (3) Strongly encourage the use of an ISO 8601 date-time in a > > comment after the required field, specifying that it should use > > UTC ("Zulu") time only. > Strongly disagree. > The first lesson I learned in engineering school, in an engineering > drawing class, was (as best I can recall the wording) "don't dimension > the same point or line relative to more than one reference".   This > lesson hit home because I had already made that mistake, in naively > drawing up something to be built (a extra console for a planetarium).   > The result was exquisitely crafted, and simply did not fit and could not > be made to fit where it needed to fit.   I didn't realize the nature of > my mistake until I actually started taking engineering classes.   Even > though I've rarely used the drawing skills they painstakingly taught me, > that hugely important lesson has stuck with me.   The generalization of > this is "don't define the same thing in more than one way". > Or there's the old saying "A person with one watch knows what time it > is, a person with two watches is never certain." > Don't duplicate the date-time in another format, not in a comment, not > in another header field.   Have exactly one indication of the date that > the message was sent. As I noted before, it's quite easy to end up with code that usually, but not always, produces the same time stamp. > > (4) Change the syntax to what we would, I think, specify today, > > defining the current syntax as an obsolete feature and perhaps > > encouraging its inclusion in a comment. > Strongly discourage this also.   There's nothing wrong with the current > format. And even if there were, it would have to be very very wrong in order to justify a recharter of the WG in order to have the leeway to do this. > John Levine wrote: > > How about if we pare down the definition of date-time to the minimum > > > > DD Mon YYYY HH:MM:SS +0000 > > > > and deprecate everything else including the optional day of week and > > anything other than UTC. I would think this would be easier to explain > > and easier for people to get correct. If we had a mechanism for this, perhaps. But we don't. Obsolete syntax is not an option. > I could see discouraging the inclusion of the day-of-the-week (while > still making it optional), as it's redundant at best and creates > unnecessary errors at worst. > I don't support getting rid of the timezone offset and normalizing > everything to GMT, first because it's error-prone, and second because > the timezone of the originator is actually useful to the recipient (even > though, sadly, many mail readers try to hide such information). Yep. > cketti wrote: > > (5) Define new header fields, move current ones (as far as I can tell > > this concerns "Date" and "Resent-Date") to obsolete syntax. Define a > > transition period where MUAs should use both variants when creating > > messages. After a cutoff date MUAs should only create messages using > > the new header fields. > No, please no.   In addition to having two sources of the same > information (see above), it would accomplish nothing beyond adding > additional complexity and failure states.  MUAs need to be able to read > messages that are decades old because some people keep email around > forever, and messages can be archived for historical purposes. And they also select messages from archives and forward them. I've seen decades-old mesages resurrected and forwarded. The fact that this works is actually a tribute to the quality of the design. Try doing something similar with decades old word processing files and see what happens. Like it or not, there's no way to prevent essentially any part of the email infrastructure from being exposed to old messages. > If there's any benefit to simplifying the message format, it's in making > new generators of email less likely to produce errors. It does nothing > for email readers that generally need to be able to read things at least > as old as RFC822 format (including pre-DNS email addresses) and maybe > even RFC733 format (e.g. with " at " permitted between local-part and host). > John Klensin again: > > The issue that dates, as specified in RFC5322, have poor > > internationalization/localization properties. > If we wanted to fix this I'd say add the Olsen timezone as a comment > following the GMT offset.   But there are too many (IMO broken) MUAs > that already believe it is a Good Thing to hide the original timezone > from the recipient (as well as much else that is valuable, like the > sender's and recipients' email addresses).   And large numbers of hosts > (think both mobile devices and IoT appliances) have a hard enough time > getting their GMT offset right.   If the value is likely to be wrong, > it's better to not include it at all than for the sending host (or > worse, some intermediary) to guess. It has taken decades for calendar apps to (mostly) get this right, and unlike MUAs, where date/time displays are a UI detail, they're central to a calendar app. > John Levine: > > It is my impression that most MUAs parse the date header and redisplay it > > in a local format. Even Alpine, which has a pretty minimal user interface, > > does that. > Just because "most" MUAs do something doesn't mean it's a good idea.  > I'm fairly appalled at the behavior of some MUAs that insist on hiding > useful information from recipients for the sake of... something.   > Probably to make it fit on tiny screens or something. Right, like hiding addresses in favor showing the preceeding phrase. > IMO the usefulness of email has been seriously degraded by several > factors, one of which is that MUAs are much less functional than they > used to be.   Let's not try to encourage more of that. > Ned Freed: > > (2) The idea of moving stuff like the leading weekday to the obsolete > > syntax may seem attractive, but would in fact be an interoperability > > disaster as new implementations appear that fail to accept obsolete > > syntax (no matter that the standard says they're supposed to) and > > the gazillion existing implementations fail to upgrade. > > > > This is an especially serious concern because right now the stuff > > in the obsolete syntax is for the most part something implementations > > *can* ignore and get away with it. A subsetting of the Date: > > field syntax, OTOH, is nothing of the sort. > There's something to be said for not making the specifications > (especially the portion that mail readers have to pay attention to) any > more complex than they already are, because this seems to have the > effect of making implementations buggier. > Dave Crocker: > > The mere fact that a protocol or format was designed a long time ago > > does not mean it needs to be replaced. And displacing a specification > > that has been in global use for 45 years ought to set a very high bar > > and demand quite a bit of clear and compelling basis for replacing it. > +1 to both.   And IMO we should consider a specification that has been > mostly stable for 45 years and continues to be in widespread use a huge > success story, rather than an indication that something is wrong.   IETF > needs more success stories like this. > *** > 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. > Alessandro Vesely: > > It is already quite difficult to find correct implementations for the > > accepted grammar.  Requiring that obs- be also implemented can push > > compliance so far that no programmers will want to tackle it.  > > Perhaps, proposing a reachable target can improve parsers quality... > Sounds like we need pointers to some reference implementations.   These > days it's rare that anyone should need to implement a protocol entirely > from the specifications. We really need to pay more attention to this fact in our discussions. People rarely write MUAs from scratch any more; they rely on libraries to do most of the parsing, message construction, and so on. This is great when the library is high quality. OTOH, it's terrible when the library stinks, because libraries can be very difficult to upgrade. > John Levine: > > I can't recall the last time I saw a route in an address, or a space > > before the colon in a header in non-spambot mail. > I have, on multiple occasions within the past five years, been required > to read copious volumes of email dating from the 1980s, and testify to > its likely authenticity or lack thereof.   I can't recall the last > occasion I saw such a message in current email, but it's still necessary > to be able to read email dating from decades ago.   And this will become > even more necessary in the future as more and more of our historical > records exist only in digital form. It would be "today" for me, but that's because we use source routes internally. OTOH, I still see %-hacks pretty regularly. Bang paths seem to have died, thank goodness. Spaces before the colon still show up from time to time. We notice because they don't interact well with milter. Ned From nobody Tue Apr 27 15:51: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 904623A23FC for ; Tue, 27 Apr 2021 15:51:19 -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 XM-dxJIoch5m for ; Tue, 27 Apr 2021 15:51:15 -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 C06243A23FA for ; Tue, 27 Apr 2021 15:51:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 5A05EE320610 for ; Tue, 27 Apr 2021 17:51:03 -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 DTTcXvoaeJCe for ; Tue, 27 Apr 2021 17:51:02 -0500 (CDT) Received: from [172.16.1.16] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 163AEE320608 for ; Tue, 27 Apr 2021 17:51:02 -0500 (CDT) From: Pete Resnick To: emailcore@ietf.org Date: Tue, 27 Apr 2021 17:51:00 -0500 X-Mailer: MailMate (1.14r5798) Message-ID: In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown 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, 27 Apr 2021 22:51:20 -0000 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. As for Alessandro's propsal: On 26 Apr 2021, at 5:54, Alessandro Vesely wrote: > After Pete's examples, it is clear that there is a treasure trove of > older mail archives. From such perspective, it doesn't sound so > misleading to call their format "obsolete". It is an old format, no > longer in use. > > Specifying the scope of obs- syntax might seem to weaken the MUST > somewhat, for example like so: > > OLD: > 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. > > NEW: > 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. 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. However, old mail archives exist and are > being > being actively preserved. Parsers which may happen to be applied > to > such content MUST be able to interpret obs- elements, and hence be > fully conformant to this specification. To quote Keith and Ned from the other thread: On 26 Apr 2021, at 20:23, Ned Freed wrote: > On 26 Apr 2021, at 19:47, Keith Moore wrote: > >> MUAs need to be able to read >> messages that are decades old because some people keep email around >> forever, and messages can be archived for historical purposes. > > And they also select messages from archives and forward them. > I've seen decades-old mesages resurrected and forwarded. > > The fact that this works is actually a tribute to the quality of the > design. > Try doing something similar with decades old word processing files and > see what happens. > > Like it or not, there's no way to prevent essentially any part of > the email infrastructure from being exposed to old messages. and: >> John Levine: > >>> I can't recall the last time I saw a route in an address, or a space >>> before the colon in a header in non-spambot mail. > >> I have, on multiple occasions within the past five years, been >> required >> to read copious volumes of email dating from the 1980s, and testify >> to >> its likely authenticity or lack thereof.   I can't recall the last >> occasion I saw such a message in current email, but it's still >> necessary >> to be able to read email dating from decades ago.   And this will >> become >> even more necessary in the future as more and more of our historical >> records exist only in digital form. > > It would be "today" for me, but that's because we use source routes > internally. OTOH, I still see %-hacks pretty regularly. Bang paths > seem to have died, thank goodness. > > Spaces before the colon still show up from time to time. We notice > because they don't interact well with milter. It goes beyond simply mail archives. It might be forwarding. It might be older implementations that are still around. It might be current implementations that do silly things, but that you still want to be able to accept mail from. The MUST means it is "actually required for interoperation". Keith and Ned make a pretty convincing argument that it is essential to implement the "obsolete" interpreter to interoperate, and I can't figure out what "valid reasons in particular circumstances to ignore" the requirement might be to even reduce it to a SHOULD. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Apr 27 16:00: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 9DBF53A2444 for ; Tue, 27 Apr 2021 16:00:04 -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 BohhSLqbYW7R for ; Tue, 27 Apr 2021 16:00:00 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C4C3A2442 for ; Tue, 27 Apr 2021 15:59:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lbWgQ-000E8U-9H; Tue, 27 Apr 2021 18:59:58 -0400 Date: Tue, 27 Apr 2021 18:59:52 -0400 From: John C Klensin To: Pete Resnick , emailcore@ietf.org Message-ID: <381EA4C5640CEC3D4101FFDF@PSB> In-Reply-To: References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> 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: Tue, 27 Apr 2021 23:00:05 -0000 --On Tuesday, April 27, 2021 17:51 -0500 Pete Resnick wrote: > Answering a couple of items in this reply: >=20 > On 26 Apr 2021, at 19:47, Keith Moore wrote: >=20 >> 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. >=20 > 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. =20 thanks, john From nobody Tue Apr 27 16:14: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 3B1E33A24C0 for ; Tue, 27 Apr 2021 16:14:07 -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 p18qf3yH_ZDd for ; Tue, 27 Apr 2021 16:14:02 -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 CE9773A275E for ; Tue, 27 Apr 2021 16:13:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYDDYVQRYO00FS9S@mauve.mrochek.com> for emailcore@ietf.org; Tue, 27 Apr 2021 16:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1619564891; bh=uNO8y2OIp7ZByOu2+/pir/BGteMwLAfUtWRDTSsuCHM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=eQisZOJrjeAbtM2wt4fZdDxrKV6DmJxIyI6A5MsGxZ7pqlgcw15i5kOpznZoODU4y yKZI6juk/9qcuFQOMToUEcKcHnqKFa8Y4onBa1+VXJYRh30BIRROBXnnhpiwvY50YV iGSckphbfzTQlQD+0gW/K2ZrXcFp4pLogFw5D4z8= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYDBA1ZCB40085YQ@mauve.mrochek.com>; Tue, 27 Apr 2021 16:08:07 -0700 (PDT) Cc: Pete Resnick , emailcore@ietf.org Message-id: <01RYDDYSYKQ60085YQ@mauve.mrochek.com> Date: Tue, 27 Apr 2021 16:00:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 Apr 2021 18:59:52 -0400" <381EA4C5640CEC3D4101FFDF@PSB> References: <20210424190329.B796F73FF998@ary.qy> <6e127658-100d-dd0d-19e1-7c3488ea42ad@dcrocker.net> <09BF2A137890DF17A459F62C@PSB> <381EA4C5640CEC3D4101FFDF@PSB> To: John C Klensin 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, 27 Apr 2021 23:14:07 -0000 > --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