Re: [calsify] New Timestamp Draft

Ned Freed <ned.freed@mrochek.com> Fri, 22 January 2021 18:54 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064463A13FE for <calsify@ietfa.amsl.com>; Fri, 22 Jan 2021 10:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=mrochek.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 TMrf9TNta1jQ for <calsify@ietfa.amsl.com>; Fri, 22 Jan 2021 10:54:11 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 A62A63A13FC for <calsify@ietf.org>; Fri, 22 Jan 2021 10:54:11 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RUOD5H23U800EZ4C@mauve.mrochek.com> for calsify@ietf.org; Fri, 22 Jan 2021 10:49:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1611341347; bh=zNX692zqpdhthr+o4AufFc9I2dMgsmf8u0/SpIvggUo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=mHbqcOXdUKieGvWLoG9sNBpjujQl7LoN9N+FRnXsq+4ivu3ZVrg/uBzXlqmjAyq4/ +S/1n6yIJjXFFBUPKrJzcdIqtXwE4L7c7Rn0mmVGqEdjFtYsNpHeN4CWyM2eYKFYOY m8kM+5o48NmZ2W0BTUQ8vB/ShZaQATt9pdCK8do8=
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: TEXT/PLAIN; charset="utf-8"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RUAOXM63XS005PTU@mauve.mrochek.com>; Fri, 22 Jan 2021 10:49:04 -0800 (PST)
Cc: Ujjwal Sharma <ryzokuken@igalia.com>, calsify@ietf.org
Message-id: <01RUOD5EF5WO005PTU@mauve.mrochek.com>
Date: Fri, 22 Jan 2021 10:47:18 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 22 Jan 2021 17:39:10 +0100" <EF6610AB-2A2B-485F-B3F2-E91F8751C21F@cisco.com>
References: <36725ce1-307a-945e-63bf-af98f4b85338@igalia.com> <a78e1a49-de7b-d2ed-c112-0bbd0cb62399@igalia.com> <da1b1dce-c4ce-49f2-b802-2bcbe00445c4@dogfood.fastmail.com> <23769d32-0a9b-6a8d-5f23-045f79a25fc6@igalia.com> <20210114164646.GA4932@ucolick.org> <8ae850cd-3d62-0834-5532-5f5ef14f7185@igalia.com> <EF6610AB-2A2B-485F-B3F2-E91F8751C21F@cisco.com>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/B_dT1fWoKpa711zDZORaWD1IAc0>
Subject: Re: [calsify] New Timestamp Draft
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 18:54:13 -0000

> RFC 3339 or ISO 8601 is used all over the place.  It’s used in logging,
> email, and a great many other things.  Before the IETF goes monkeying with it,
> could the authors discuss what is driving this change?  What do you want people
> to do that they didn’t do before, and what do you want them to stop doing,
> and why?

+1. The stability of this specification has been invaluable.

> Also, I suggest that this work should go through DISPATCH.  There are a lot
> of other questions.  Here’s one: is the IETF really the right organization to
> do this work in? ISO wrote the underlying spec.  They presumably thought about
> it a lot.

+1. And if there's some sort of liason with ISO or whoever is responsible 
for this, they should be engaged.

				Ned




> > On 22 Jan 2021, at 17:16, Ujjwal Sharma <ryzokuken@igalia.com> wrote:
> >
> > Hi Steve!
> >
> > Sorry for taking a while before responding to your emails.
> >
> > Talking specifically about your concerns:
> >
> >> This document needs to define the meaning of time using a term other
> >> than UTC for any date prior to 1960.
> >
> >
> > and
> >
> >> Also note that cesium hyperfine frequency ... cesium second
> >
> >> was not adopted by the SI until 1967 August.
> >
> > For both of these, I like have to point out that none of these
> > definitions were added in this update and belong to the original RFC
> > (RFC 3339). That said, if folks agree that the original RFC incorrectly
> > defines these terms and they need to be updated, I'd be happy to correct
> > them in the next revision of the draft.
> >
> > That said, I would have to point out that my knowledge in this space is
> > rather limited and therefore it would be best if you recommended exactly
> > what the replacement should be. To take things further, you could also
> > make a pull request to the project at
> > https://github.com/ryzokuken/draft-ryzokuken-datetime-extended
> > or email me a git patch if you prefer that.
> >
> > Thanks,
> > Ujjwal
> >
> > --
> > Ujjwal "Ryzokuken" Sharma (he/him)
> >
> > Compilers Hacker, Node.js Core Collaborator and Speaker
> >
> > _______________________________________________
> > calsify mailing list
> > calsify@ietf.org
> > https://www.ietf.org/mailman/listinfo/calsify