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

Metapolymath Majordomo <majordomo@metapolymath.com> Sun, 18 April 2021 01:32 UTC

Return-Path: <kw@metapolymath.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 C95FB3A3B75 for <art@ietfa.amsl.com>; Sat, 17 Apr 2021 18:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (2048-bit key) header.d=metapolymath.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 DlyrsAYi21FU for <art@ietfa.amsl.com>; Sat, 17 Apr 2021 18:32:35 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 8D45A3A3B72 for <art@ietf.org>; Sat, 17 Apr 2021 18:32:35 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id i10so14679845lfe.11 for <art@ietf.org>; Sat, 17 Apr 2021 18:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metapolymath.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kC6wl4kQWwmB+V81+0TqFIYMIWKFDqse02BW9BjqlQU=; b=ItF9pUjUFzXDI0AdG7ubljwbI2UJ4iLAGCZqgip0rtVikLuPOeadthrz9QAYL26bZ3 FxXh0Mb7glzwNgr/HHF8jJ5R7ExTpFzDXZrla8nDSUFTY4VBtEgj/H7KTG0gRXWI0HcG Ef5VAVcbhPwdTE5w8q5iPHb4NLATSbtlbe/4LJOKiZus5++5mtOPCqSCzB8OWQQlzwWa p5I4tdbCczF9J4h1rgKgVNmFd9r+WLYy306LXTdIcrd3fJzDrMOFZEfTBqr2yExUUqcp Ly/10hdvfRca9UU8Y6jSbHmwisc6kqd3o4r4ENHYavhvEs0XPU2eI8qyq/meQTEooCFZ 7mcA==
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; bh=kC6wl4kQWwmB+V81+0TqFIYMIWKFDqse02BW9BjqlQU=; b=i/PD5FZhHCD9CbVSjZON45PTBCDtR19o9jKlSH3XA/ZnGOJgeFGrjpGq2X53VPDpM2 PgfYT02V88TDotTTRWBUquHLFbDuStkbwikEGYqHZSiSfqcfGUqHed/BFEnUd+9IwAB6 5WSgncFZaaMVuElNknLyvq3ahtEzd9K/knsWmR5OyOfoKeDeN5tTW/5QpUReIDEHRISc SXnpaQXq6yUMNtr4SIL7etGqkkgUOwSJ/H2tdLQ8CZ6Mhq7FbVM+owMHfnjLM9vSpGFY m1PBHFHnnlwCs4/yWtWNKeic8iFFNFXiim4IzuBFLTD2N24/m5zEtsRtazg+R1Sh5jLx zFzw==
X-Gm-Message-State: AOAM531SF77zIumXi2QUpnDha7bDmVRYPZ8MIBOaAaww6/TEv+U4qZO5 dZTZ8zIFlDRlR+I0DiZccaOKv/rqpwNUaFpYBOE7ht1Iv+g=
X-Google-Smtp-Source: ABdhPJzdPxS57go2PUFC6X0tRb7L/W7fuEIVMeD55I+g3yYSqwBOBH1hRJHtrxk352KZ8WKc25hl/jLHwcVjhCwptgw=
X-Received: by 2002:a19:711d:: with SMTP id m29mr215327lfc.660.1618709551855; Sat, 17 Apr 2021 18:32:31 -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>
In-Reply-To: <B38A981D-A79E-4D31-B29C-A09C456E3CC6@tzi.org>
From: Metapolymath Majordomo <majordomo@metapolymath.com>
Date: Sat, 17 Apr 2021 20:32:21 -0500
Message-ID: <CABtv6o9Xq2osULhV-jYUM3fzHvJgNEyzMfFz_TQ8F4JXwHXvtw@mail.gmail.com>
To: "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d54e4405c0352fbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/0k61iEt69zTtWRvFdgQuWSdOSHI>
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:32:41 -0000

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
>