Re: [art] [saag] Date formats: RFC3339 vs. RFC 5322

Yakov Shafranovich <yakov@nightwatchcybersecurity.com> Sun, 18 April 2021 01:37 UTC

Return-Path: <yakov@nightwatchcybersecurity.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 317183A3B92 for <art@ietfa.amsl.com>; Sat, 17 Apr 2021 18:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 VvK_F_5g-qIw for <art@ietfa.amsl.com>; Sat, 17 Apr 2021 18:37:23 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BDD3A3B93 for <art@ietf.org>; Sat, 17 Apr 2021 18:37:22 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id s7so30274392wru.6 for <art@ietf.org>; Sat, 17 Apr 2021 18:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=op9iyuIecOrRX04uw4YcNgSLej+KbX6zMjWudSfL6Os=; b=t5BKGY4/TdyOdCAsc0r4RB/JEwYmpsIeZ+zk3T1ZVXLKO7DTci6NW36CnU4T7TNX6O lyeBiRw8x9rRrhfzQg9VmKk4mECi4J3XNoWCB+sHFzDkQqaj8vmAJN6/gTwv80ZQO1jr RRbIxYgTd3NbowrpI0JXlYWCG4ottOS7OG+nmaIPPVw+kzknI3nxVmcYncWnkqaARW/Q p2+OwZJ6hwUoEDWRn8h8pC7RV6KHFmqAOYbR2ffc1RPYKlGJIXfe60riUeQeVpXXAjHs 4pKBOFN7b7bkH107BGEJmHaaOt8+G3EPu+09CiPx0GEyw1xzihtyxtyySiibiVk/eQ5I SdYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=op9iyuIecOrRX04uw4YcNgSLej+KbX6zMjWudSfL6Os=; b=qMHIwYWEgX8gMF3reFvM20G3lDrKPL1VnF7xYWQKajTsoLDDhE8b1o6YQA/tfepsKC 789BwO0YQcmGUEPs5u8ei7k16bbsEUgi6wli13n6bYnbqiPdPnIo/dKMH95OO3BJ+CED 7n/tkUD6mq84dulfzWxzaGZ7XFxGWTX59zL7TuOxaTHhPQes4YfeeRJqYTyib2AwiMAK /c5ptsDglFFZ4AWG3BCOgpyb7bQtpNrbHGXofsIHSk+dhYbqVvyWvNhhhvDq6pQ/Wl1W 2oiqz0g0Xvhto2/t5hiv5w1LeMD5AzIJnAcXlJUA2QI4HB6F8bnOE8/xRlKvR8Se9bFD jjAw==
X-Gm-Message-State: AOAM531RXK/P/39fq9GtFa90hMo1Ix0pCbjPDb5We/SfH79pgmwKKGGz 1r1gns5Ib9V1/vSYdoeOz3EHiVx/JpcXTFObiQcQcA==
X-Google-Smtp-Source: ABdhPJygTs7HSGiNDYswrrI0qvz6cjFlSTGgNEkp0i1GC4mPr10GP6sMPRvAREFB2OLjUWwUxdydCEzXrVNZadwjlFo=
X-Received: by 2002:a5d:4fc9:: with SMTP id h9mr6457385wrw.172.1618709839328; Sat, 17 Apr 2021 18:37:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAAyEnSMBdXCA0EvgR79P_1gi15pAPfeyu_HgGqgMjWxRP8sxKg@mail.gmail.com> <C7B5DB45-F0A1-491C-AD4E-91F67C8C182E@cisco.com> <B3D690C21848AF07EC92577F@PSB> <CAMm+LwiNGDMF9muA0p3uYALSiPFNEpZ5vrkyXRnUzqdBL02Jjw@mail.gmail.com> <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> <B38A981D-A79E-4D31-B29C-A09C456E3CC6@tzi.org> <CABtv6o9Xq2osULhV-jYUM3fzHvJgNEyzMfFz_TQ8F4JXwHXvtw@mail.gmail.com>
In-Reply-To: <CABtv6o9Xq2osULhV-jYUM3fzHvJgNEyzMfFz_TQ8F4JXwHXvtw@mail.gmail.com>
From: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>
Date: Sat, 17 Apr 2021 21:36:43 -0400
Message-ID: <CAAyEnSNXjSDJON=zxsEvPVhLw99YP-ZvFXu1H3dkZKbas0nPBA@mail.gmail.com>
To: Metapolymath Majordomo <majordomo@metapolymath.com>
Cc: "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, IETF SAAG <saag@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/N1zVf7y0gFWeok6IIBqtQZ2_PMY>
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: Sun, 18 Apr 2021 01:37:27 -0000

I think the consensus is clear - to use ISO 8601 / RFC 3339. Thank you all!

On Sat, Apr 17, 2021 at 9:32 PM Metapolymath Majordomo
<majordomo@metapolymath.com> wrote:
>
> Hi Yakov,
>
> I'm inclined to agree with Carsten.
> RFC 3339 section 5 seems to cover the general guide and recommends use of ISO 8601 for internet protocols. To the point on fractions of a second with RFC 3339 § 5.3 Rarely Used Options.
>
> Then my current understanding when a rarely used option is needed for communicating an information interchange that needs such precision the use of
> ISO 8601-1:2019 and ISO 8601-2:2019 contain the guidance for what should be used.
>
> That being noted, was there something of security interest that is not fully covered by RFC 3339, ISO 8601-1:2019 and ISO 8601-2:2019 or a proposed RFC for SAAG that is not covered by these standards that we can look at specifically that you're concerned about? If so, please provide your specific concerns.
>
>
>
> With Regard,
>
> Kronah Wood
> Metapolymath, LLC
> PO Box 19236
> Lenexa, KS 66219-9236
> +1.2139158297
>
> Sent from Mobile
>
>
>
>
>
>
> On Sat, Apr 17, 2021, 7:30 PM Carsten Bormann <cabo@tzi.org> wrote:
>>
>> On 2021-04-14, at 22:53, Mark Baushke (ietf) <mbaushke@gmail.com> wrote:
>> >
>> > Twelve digits after the decimal point expresses pico seconds which is just silly and unrealistic at present, but micro seconds seem plausible in many contexts. If new standards are forward looking, then the expression should possibly be considered.
>> > (I do not see a need to consider femto, atto, zepto, or yacto seconds at the present time.)
>>
>> I don’t know why this discussion is continuing on the SAAG list, but let me add one factoid anyway:
>>
>> The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond resolution [1] because the Haskell date/time libraries need that (which in turn probably just try to be one step ahead of UNIX nanosecond resolution).  (The CBOR tag also has femtosecond and attosecond resolution, because these are still cheap with 64-bit integers.  Zeptoseconds, yoctoseconds, and anything else down to and beyond Planck units can be added later based on bignums.)
>>
>> A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~ 0.3 mm (~   12 thou), which is well beyond the tolerances to which e.g. connectors can be manufactured, so while these are not easy to achieve as date-time precisions, as durations (time differences) they are in wide use (as are femtoseconds and even attoseconds).
>>
>> RFC 3339 has no problem with decimal fractions at all, so there is no need for invention as long as we talk about text strings for date-times.
>>
>> Grüße, Carsten
>>
>> [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#name-keys-3-6-9-12-15-18
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art