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

Steffen Nurpmeso <steffen@sdaoden.eu> Tue, 02 August 2022 23:14 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 5C1D4C14F722 for <emailcore@ietfa.amsl.com>; Tue, 2 Aug 2022 16:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Level:
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 Ez_3nJ4GRGTJ for <emailcore@ietfa.amsl.com>; Tue, 2 Aug 2022 16:14:15 -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 E6DC4C14F720 for <emailcore@ietf.org>; Tue, 2 Aug 2022 16:14:14 -0700 (PDT)
Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 7096E16059; Wed, 3 Aug 2022 01:14:10 +0200 (CEST)
Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 4BCE592C2F; Wed, 3 Aug 2022 01:14:08 +0200 (CEST)
Date: Wed, 03 Aug 2022 01:14:08 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: John C Klensin <john-ietf@jck.com>
Cc: emailcore@ietf.org
Message-ID: <20220802231408.xOC-e%steffen@sdaoden.eu>
In-Reply-To: <305AE7DFC0554733F7C75AAD@PSB>
References: <20220802031735.E29F746F2656@ary.qy> <305AE7DFC0554733F7C75AAD@PSB>
Mail-Followup-To: John C Klensin <john-ietf@jck.com>, 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.
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/5bVzbynufj_PmXxKiaCp_QjP_ew>
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: Tue, 02 Aug 2022 23:14:17 -0000

Unfortunately i am unable to create an issue who knows where.

John C Klensin wrote in
 <305AE7DFC0554733F7C75AAD@PSB>:
 |--On Monday, August 1, 2022 23:17 -0400 John Levine
 |<johnl@taugh.com> wrote:
 |> It appears that John C Klensin  <john-ietf@jck.com> said:
 |>> I may be unique, but, if a user in, e.g., +0400 sends me a
 |>> message at 02:00, I'd prefer that my MUA leave that alone
 |>> rather than standardizing to UTC because known that the
 |>> sender composed and sent the message at 2AM is useful
 |>> information for me (hence the suggestion about comment fields)
 |> 
 |> I don't think you are, but that is definitely between you and
 |> your MUA, which can display dates any way it wants, not limited
 |> to anything defined in RFC 5322.
 |
 |Well, it can display them any way it wants (which is what I said
 |before at least twice, so we agree) but only if it has adequate
 |information.  If the MUA at the sending end, or any MTA in the

You were talking about time zone standardization, but this is all
politics.  A very large amount of the world population even live
in calendars that are not comparable to Gregorian date.  It can
change at any time.  Giving a sentence of advise for these cases
seems a viable and advisable change in my opinion.

 |path, changes a time that was originally expressed locally to
 |UTC (or to its own local time), then the receiving MUA doesn't
 |have enough information to reinterpret the time back to the
 |sender's time.   And I really hope this does not lead to a

The internet message format is it that does not offer sufficient
methods to cover the time zones of the world.
People try to circumvent that by enforcing UTC so that receiving
software can at least detect the correct time when the sender
produced the message!
My question or suggestion was _solely_ whether the standard wants
to throw words towards the "-0000" that the RFC mentions as

  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.

because the widely used MTA exim does not do that (or did not when
the patch was committed in 2020, i did not look at the current
code base).

 |proposal for an Originator-location: header field that would
 |express the originating user's location in time zone, latitude
 |and longitude, and maybe other terms.  :-(

You are overly polemic for no reason.

  ...
 |> PS:
 |> 
 |>>> The only difference between 19:39:03 UT and 19:39:03 +0000
 |>>> would be that the latter could be assumed to be local time
 |>>> (so we can take a (very rough) guess at their location, and
 |>>> also
 |> 
 |> Reykjavik and Dakar really aren't very close to each other.
 |
 |Indeed.  Neither are London, Timbuktu, Tórshavn, and Jamestown
 |(Saint Helena), all of which, with the correct chose of dates,
 |use +0000.   If he has said "guess at their longitude", that
 |would be been somewhat less rough, but maybe not enough to be
 |useful.

I want to point out that these time zones can be losslessly
converted back and forth, whereas others might not.
Since the [+-]0000 ship has sailed and [+-]000000 is not about to
happen, the advise to use UTC when the resulting seconds of
creating localtime(3) and gmtime(3) from the same time(3) differ
seems a good one.  All MTAs i looked into use localtime(3), most
also gmtime(3) (OpenSMTPD not).

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