Re: [art] [saag] Date formats: RFC3339 vs. RFC 5322
Nico Williams <nico@cryptonector.com> Tue, 13 April 2021 20:01 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290A93A2585; Tue, 13 Apr 2021 13:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGLI5rvZ9Ktq; Tue, 13 Apr 2021 13:01:11 -0700 (PDT)
Received: from giraffe.apple.relay.mailchannels.net (giraffe.apple.relay.mailchannels.net [23.83.208.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1D43A2583; Tue, 13 Apr 2021 13:01:11 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 280B24822E3; Tue, 13 Apr 2021 20:01:10 +0000 (UTC)
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-96-27-180.trex.outbound.svc.cluster.local [100.96.27.180]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CCD104822FA; Tue, 13 Apr 2021 20:01:08 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.27.180 (trex/6.1.1); Tue, 13 Apr 2021 20:01:10 +0000
X-MC-Relay: Good
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Imminent-Cooperative: 67b84cf25cf8e252_1618344069180_4176549922
X-MC-Loop-Signature: 1618344069180:1491392068
X-MC-Ingress-Time: 1618344069179
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id 769F988834; Tue, 13 Apr 2021 13:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=/qmQKtGqSfBbRp8GEcfWbADhKN8=; b=HF73J7GgwGf 15/gGiCjV2zSbJJ8svidhY5KHY1SrP/Sk568/7w478tfu9RfLNMLFKc89NtOEtPP t342IzpZSzdaf+3E46Uy2a95TmpOnsx0jUZpW9XjeqtHiIHRBz+w1ePKvVScbOrc e8BWrC9a1YuVqf4549pwEM/N7zwNjvTc=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 4E7358883B; Tue, 13 Apr 2021 13:01:04 -0700 (PDT)
Date: Tue, 13 Apr 2021 15:01:02 -0500
X-DH-BACKEND: pdx1-sub0-mail-a57
From: Nico Williams <nico@cryptonector.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>, art@ietf.org, saag@ietf.org
Message-ID: <20210413200101.GL9612@localhost>
References: <CAAyEnSMBdXCA0EvgR79P_1gi15pAPfeyu_HgGqgMjWxRP8sxKg@mail.gmail.com> <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/klxzoyDi99m_xeh2elp8QqBO7wo>
Subject: Re: [art] [saag] Date formats: RFC3339 vs. RFC 5322
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 20:01:16 -0000
On Tue, Apr 13, 2021 at 12:30:21PM -0700, Paul Hoffman wrote: > Given that the date in that section of that draft is meant to be machine > parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad idea, > given the existence of RFC 3339. I mean, strptime() can handle both, and since everything is written in C (which is why we so badly need security.txt!), that's enough. But yes, ISO 8601 is much easier to parse. And it will be even easier to compare dates if security.txt ends up using Zulu time, since then plain string comparison (even memcmp()!) is enough. Thinking about implementation... I suddenly wonder why security.txt should have expiration instead of a TTL. I'm pretty sure what's really intended is that I not cache security.txt files too long so that they can be updated. Indeed, sections 3.5.5 and 6.3 make it clear that this is about caching. An optional publication time (ISO 8601), and a required TTL measured in hours or days would be more than sufficient, and maybe superior to a notAfter. Unless the point of `Expires` is also to force the publisher to keep security.txt up to date. Implementation-wise, I see a few ways in which I would handle `Expires` information: 1) Comparison. E.g., to determine if a security.txt is stale, or to sort/index/search archived security.txt files, in which case I'd have two choices: 1a) if the format is ISO 8601 zulu, then format current time then string compare, 1b) parse the `Expires` into local time of day form and compare to current time. (1a) is simpler, but only works for ISO 8601 Zulu times. 3) Authoring/production of security.txt files, where I only need to format time, not parse it. Clearly it's easier to only have to format time and never have to parse it. That said, strptime() and similar are widely available and easy enough to use, so I do think there's an readability argument to make. But ISO 8601 is still easier to read than RFC 5322 time, especially for non-English speakers. Nico --
- [art] Date formats: RFC3339 vs. RFC 5322 Yakov Shafranovich
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Eliot Lear (elear)
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Tim Bray
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Nico Williams
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Nico Williams
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Paul Hoffman
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Julian Reschke
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Nico Williams
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… John C Klensin
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Claudio Allocchio
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Randy Bush
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Ned Freed
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Michael Douglass
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Dave Crocker
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Stian Soiland-Reyes
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Peter Gutmann
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Alan DeKok
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Tony Finch
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… heather flanagan
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… John Levine
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… tom petch
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Steve Allen
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… heather flanagan
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Phillip Hallam-Baker
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Benjamin Kaduk
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… tom petch
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Stian Soiland-Reyes
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Phillip Hallam-Baker
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Steve Allen
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Phillip Hallam-Baker
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Carsten Bormann
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Metapolymath Majordomo
- Re: [art] [saag] Date formats: RFC3339 vs. RFC 53… Yakov Shafranovich