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

"Peter J. Holzer" <hjp@hjp.at> Mon, 01 August 2022 20:10 UTC

Return-Path: <hjp@hjp.at>
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 88665C159493 for <emailcore@ietfa.amsl.com>; Mon, 1 Aug 2022 13:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham 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 xg1BFpi9tw1L for <emailcore@ietfa.amsl.com>; Mon, 1 Aug 2022 13:10:10 -0700 (PDT)
Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (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 6830FC15948D for <emailcore@ietf.org>; Mon, 1 Aug 2022 13:10:09 -0700 (PDT)
Received: by rorschach.hjp.at (Postfix, from userid 1000) id ACDB976B4; Mon, 1 Aug 2022 22:10:06 +0200 (CEST)
Date: Mon, 01 Aug 2022 22:10:06 +0200
From: "Peter J. Holzer" <hjp@hjp.at>
To: emailcore@ietf.org
Message-ID: <20220801201006.5ohqw7x56ezv4kns@hjp.at>
References: <20220801174340.tQBME%steffen@sdaoden.eu> <969063F2609AB90C285E5B77@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="plushldz54m5qtse"
Content-Disposition: inline
In-Reply-To: <969063F2609AB90C285E5B77@PSB>
Autocrypt: addr=hjp@hjp.at; prefer-encrypt=mutual; keydata= mDMEYZAfcBYJKwYBBAHaRw8BAQdAXKDp3VtUDNCoavz8e64LY57nUgLb87BIWKKVeiYyrKG0Cmh qcEBoanAuYXSIkAQTFggAOBYhBGlL9LrG4q2XPF4D32wA7r0ipP8fBQJhkB9wAhsDBQsJCAcCBh UKCQgLAgQWAgMBAh4BAheAAAoJEGwA7r0ipP8fSrgBAO0eJbb9Mm9wQ7a3/h6yGdb3wf2tN5V3R 9ZHBFU3lKdSAQDHmNxTvO4MWk0nn3Glmv02Ee0u6pZheZ7zAOszklwAC7g4BGGQH3ASCisGAQQB l1UBBQEBB0ArGG3CcWNFMfqtBJP6NQX6XRoOdJNyrI7lj2a1S07HdgMBCAeIeAQYFggAIBYhBGl L9LrG4q2XPF4D32wA7r0ipP8fBQJhkB9wAhsMAAoJEGwA7r0ipP8fEf4A/3hc6JbvSGyXV9HMi5 NpXKQSqQeVReugknyhEM4xMd4mAP9mjwJArc3ZAyV33xKpnQ+TKUdshYrhjo3xPZWiaK4MAQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/bwZvpjnxxACyTpT5gcT7xv0Q16o>
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 20:10:14 -0000

On 2022-08-01 14:50:51 -0400, John C Klensin wrote:
> --On Monday, August 1, 2022 19:43 +0200 Steffen Nurpmeso
> <steffen@sdaoden.eu> wrote:
> > 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:

[...]

> As far as the seconds themselves, 5322bis defines time as
>      time-of-day zone
> and time-of-day as
>      hour ":" minute [ ":" second ]
> 
> So I don't understand the problem.

It's not about the time, it's about the time zone. The user is
apparently using a time zone which is non-integral number of minutes
from UTC (not sure why someone would do that). So for example, if I was
a time traveller who wrote an email from Vienna in 1900, my offset from
UTC would be 1 hour, 5 minutes and 28 seconds, so I would need to
construct a date header like

    Date: Mon, 01 Aug 1900 22:01:31 +01:05:28

except that that's not valid RFC5322 syntax ((FWS ( "+" / "-" ) 4DIGIT)
/ obs-zone).


> (3) Add a sentence or two similar to Steffen's above or
> something that indicates that "UT" really indicates UTC at the
> time the date-time was inserted in the message, i.e., that, if
> compared to UTC six months earlier or later, they would be six
> months apart, not six months maybe plus or minus an hour or so.

I don't think that would make any difference for comparisons. 

1 Aug 2022 19:39:03 UT would specify exactly the same point in time as
1 Aug 2022 19:39:03 +0000 or 1 Aug 2022 15:39:03 -0400.

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 that they were staying late at
the office) while the former gives no such information.

I'm not sure how useful that is. A system can already convey the same
information by using "-0000" as the offset. "UT" is marginally more
readable, but you'd have to read the RFC anyway to be sure about the
semantics.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"