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

John C Klensin <john-ietf@jck.com> Tue, 02 August 2022 08:00 UTC

Return-Path: <john-ietf@jck.com>
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 AABC4C15A729 for <emailcore@ietfa.amsl.com>; Tue, 2 Aug 2022 01:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 fVdepNWNcXBC for <emailcore@ietfa.amsl.com>; Tue, 2 Aug 2022 01:00:09 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21179C159490 for <emailcore@ietf.org>; Tue, 2 Aug 2022 01:00:08 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1oImox-000OF5-2E; Tue, 02 Aug 2022 04:00:07 -0400
Date: Tue, 02 Aug 2022 04:00:01 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, emailcore@ietf.org
Message-ID: <305AE7DFC0554733F7C75AAD@PSB>
In-Reply-To: <20220802031735.E29F746F2656@ary.qy>
References: <20220802031735.E29F746F2656@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/4RHTlOhEmFCY2uzzPqvmUkzxfp0>
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 08:00:14 -0000


--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
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
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.  :-(

>> ....  However if a user sends
>> out a message that says, e.g., "next meeting same time next
>> week as the time this message was sent" in the wrong place
>> and at the wrong time of year, that could be the same time or
>> an hour earlier or later, depending.  My recollection is that
>> SEDATE is trying to figure out how to handle that issue. 
> 
> I hope they succeed but in my experience it is hopeless.  I
> have had to argue with intelligent people with technical
> degrees from reputable universities who believe that EDT and
> EST are the same, and were baffled when I told them that when
> the time changed, people in other countries would be an hour
> late for a weekly meeting.

I have had the same experience and tried to spend a little time
explaining some of those issues to those most active in SEDATE.
Unfortunately, at IETF 114, SEDATE was scheduled opposite RSWG
and I know where both you and I needed to be.

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

    best,
    john