Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis-03

Steffen Nurpmeso <steffen@sdaoden.eu> Mon, 01 August 2022 17:43 UTC

Return-Path: <steffen@sdaoden.eu>
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 BA3A8C14F723 for <emailcore@ietfa.amsl.com>; Mon, 1 Aug 2022 10:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level:
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwONNHHQBvo3 for <emailcore@ietfa.amsl.com>; Mon, 1 Aug 2022 10:43:46 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D058FC14CF08 for <emailcore@ietf.org>; Mon, 1 Aug 2022 10:43:45 -0700 (PDT)
Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 815521605B; Mon, 1 Aug 2022 19:43:42 +0200 (CEST)
Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 940DA92BF3; Mon, 1 Aug 2022 19:43:40 +0200 (CEST)
Date: Mon, 01 Aug 2022 19:43:40 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: emailcore@ietf.org
Message-ID: <20220801174340.tQBME%steffen@sdaoden.eu>
In-Reply-To: <bb5586f4-42c1-fb5c-e076-76fb56ad0d68@isode.com>
Mail-Followup-To: emailcore@ietf.org
User-Agent: s-nail v14.9.24-282-gca8e98f6b0
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: <https://mailarchive.ietf.org/arch/msg/emailcore/OEwxOYEabI518_0m7r9vO57O0HI>
Subject: Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis-03
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2022 17:43:47 -0000

Hello.

(Replying to Msg-Id copied from mail archive.)

For the MUA i maintain i have a user request regarding timezone
usage, and reading the according paragraph in the above document
i thought maybe a clarification or guidance may be a good thing to
improve the situation in the future in general.

The user uses a TAI timezone locally, a timezone where the offset
from UTC has second precision.  This is a quite common situation
for at least past timezones, too:

  $ grep -A0 -E '[[:digit:]]+:[[:digit:]]+:[[:digit:]]+' \
      /usr/share/zoneinfo/tzdata.zi | grep -v -- -- | wc -l
  410

The user wants me to forcefully overwrite the local timezone
and instead use UTC in cases where second precision is required,
as RFC 5322 only supports minute precision, and when looking at
the generated message again the date is of course wrong.
The same user made an identical request to the exim MTA in 2020,
and they seem to follow it, at least in parts.  They simply switch
to UTC, whereas i thought the following would apply better:

  Though "-0000" also indicates Universal Time, it is used to
  indicate that the time was generated on a system that may be in
  a local time zone other than Universal Time and that the
  date-time contains no information about the local time zone.

Maybe the standard should explicitly mention the above approach
for all timezones which require second precision not to loose the
correct timestamp?

--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)