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

Russ Allbery <eagle@eyrie.org> Thu, 04 August 2022 19:34 UTC

Return-Path: <eagle@eyrie.org>
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 603C3C15A722 for <emailcore@ietfa.amsl.com>; Thu, 4 Aug 2022 12:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_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 LDjVCtei8zLi for <emailcore@ietfa.amsl.com>; Thu, 4 Aug 2022 12:34:42 -0700 (PDT)
Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (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 BF1C5C157B4F for <emailcore@ietf.org>; Thu, 4 Aug 2022 12:34:42 -0700 (PDT)
Received: from lothlorien.eyrie.org (96-90-234-101-static.hfc.comcastbusiness.net [96.90.234.101]) (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 haven.eyrie.org (Postfix) with ESMTPS id 0D8E4118607; Thu, 4 Aug 2022 12:34:39 -0700 (PDT)
Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 9282AB41C43; Thu, 4 Aug 2022 12:34:37 -0700 (PDT)
From: Russ Allbery <eagle@eyrie.org>
To: John C Klensin <john-ietf@jck.com>
Cc: Julien ÉLIE <julien@trigofacile.com>, emailcore@ietf.org
In-Reply-To: <8A3BAF234B4580D591240172@PSB> (John C. Klensin's message of "Thu, 04 Aug 2022 08:45:23 -0400")
Organization: The Eyrie
References: <20220802031735.E29F746F2656@ary.qy> <305AE7DFC0554733F7C75AAD@PSB> <20220802231408.xOC-e%steffen@sdaoden.eu> <3e5240b4-12ad-0fa1-398a-659a074e46d7@wizmail.org> <20220803223222.OopI_%steffen@sdaoden.eu> <f2e46271-de99-20d4-68ea-a33f560f11d6@trigofacile.com> <8A3BAF234B4580D591240172@PSB>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Date: Thu, 04 Aug 2022 12:34:37 -0700
Message-ID: <87pmhf246q.fsf@hope.eyrie.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/uOZJNs7efokwCwr_2BImKREZQKY>
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: Thu, 04 Aug 2022 19:34:47 -0000

John C Klensin <john-ietf@jck.com> writes:

> (1) Is it desirable to change 5322bis to allow a time zone to express
> non-integral minutes?  From the discussion I think the answer is "no",
> if only because these are supposed to indicate actual time zones rather
> than being, e.g., precise indicators of local time.

There are historic time zones that have offsets of non-integral minutes,
but generally these are attempts to represent local mean time (LMT) from
eras before standardized time zones and thus only involve historic time
stamps.  It's hard to see how these would be relevant to the definition of
the Date header in email (or netnews) messages.  I think there may be a
few areas of the world with relatively late transitions from LMT, possibly
as late as the 1970s in exceptional cases (I cannot remember off-hand),
but the overwhelming majority of such zones only make sense for times
prior to the invention of email.

It's of course possible that some government may introduce a time zone in
the future with a non-integral offset because governments do some very
strange things, but it doesn't seem likely enough to warrant trying to
anticipate, at least to me.

> (2) Should "UT" be taken off the "obs-*" list and added back into valid
> current syntax to allow systems to be clear about what is intended,
> rather than having to guess at the intended semantics of "+0000" and
> "-0000".  I still feel that might be a good idea, but I'm not seeing
> much traction for it.

I'm not sure anyone who hasn't been deeply involved in the standards
process has any idea that +0000 and -0000 mean different things, but I'm
also not sure that adding UT will be any clearer or more likely to
communicate to someone who isn't deep into reading the standards.

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>