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)
- [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis… Alexey Melnikov
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Alexey Melnikov
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Alexey Melnikov
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Todd Herr
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Alexey Melnikov
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Todd Herr
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Ken Murchison
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Peter J. Holzer
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Peter J. Holzer
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Peter J. Holzer
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Jeremy Harris
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Steffen Nurpmeso
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Julien ÉLIE
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John C Klensin
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Julien ÉLIE
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… John Levine
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Russ Allbery
- Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc532… Alexey Melnikov
- [Emailcore] Time zones (was: Re: WGLC: draft-ietf… John C Klensin
- Re: [Emailcore] Time zones Russ Allbery
- Re: [Emailcore] Time zones (was: Re: WGLC: draft-… Steffen Nurpmeso
- Re: [Emailcore] Time zones John C Klensin
- Re: [Emailcore] Time zones Russ Allbery
- Re: [Emailcore] Time zones John Levine
- Re: [Emailcore] Time zones (was: Re: WGLC: draft-… John C Klensin
- Re: [Emailcore] Time zones (was: Re: WGLC: draft-… Steffen Nurpmeso
- Re: [Emailcore] Time zones Keith Moore