Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate)

ned+dispatch@mrochek.com Wed, 09 June 2021 15:21 UTC

Return-Path: <ned+dispatch@mrochek.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514213A1BAA for <dispatch@ietfa.amsl.com>; Wed, 9 Jun 2021 08:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_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=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 xqrhycPIhK9C for <dispatch@ietfa.amsl.com>; Wed, 9 Jun 2021 08:21:38 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 17B5A3A1BA8 for <dispatch@ietf.org>; Wed, 9 Jun 2021 08:21:37 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0101VLVI800FNZV@mauve.mrochek.com> for dispatch@ietf.org; Wed, 9 Jun 2021 08:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1623251791; bh=2WgvFekpONUyY2ZVPP61xyBVLqZsTBPHTi3FiBIuveo=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=nOismesZIwZLZLDGB80bgSKk5q/0nNZKGX13rxrtB7clt0XHati1KlR/dJOMUionC 1RPq69FOcBeMPHdZpzIFUSDAByvRZGcE5QA6A92ivtNCH1a8eZ4+3zgPY26WimcBgL Up3tWiW780fTa9K3CPkaA+FTiiDA6cbLSdh0J3ps=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSK5M2ZAO0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Wed, 9 Jun 2021 08:16:24 -0700 (PDT)
From: ned+dispatch@mrochek.com
Cc: Ned Freed <ned.freed@mrochek.com>, ned+dispatch@mrochek.com, Bron Gondwana <brong@fastmailteam.com>, dispatch@ietf.org
Message-id: <01S0101Q8IDO0085YQ@mauve.mrochek.com>
Date: Wed, 09 Jun 2021 07:25:50 -0700
In-reply-to: "Your message dated Wed, 09 Jun 2021 00:34:06 +0530" <bc3fb8ff-1edc-3d96-ccc9-ff25f050174b@igalia.com>
References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <EEA84B36-BEA8-43F2-98F1-7C1BD817278F@ericsson.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <d526ea17-ab34-434d-8117-d90aa8b7748f@dogfood.fastmail.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> <de092e0f-844e-c631-ab9f-96a6e22d2a3a@igalia.com> <01RZZGWED8R80085YQ@mauve.mrochek.com> <bc3fb8ff-1edc-3d96-ccc9-ff25f050174b@igalia.com>
To: Ujjwal Sharma <ryzokuken@igalia.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/I_nNZxhkWdUsoONQJ9NSx_FQLLY>
Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 15:21:42 -0000

> On 08/06/2021 18.00, Ned Freed wrote:
> > Second, this document illustrates very nicely why the charter needs to nail down
> > what is and isnt't allowed in a potential 3339bis: Despite its limited scope it
> > retains the completely gratuitous changes to the 3339 ABNF the other document
> > had. As I pointed out in my original review, it is essential that the ABNF
> > remain as stable as possible, in order to prevent breakage in other documents
> > that reference specific productions. If you want to see how this is done I
> > suggest looking at how RFC 6532 did it for the productions in RFC 5322.

> As I mentioned previously, your review was the first time it was raised
> to me and I understand the concern completely. As a matter of fact, I
> already submitted a new version of the draft to fix that:
> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/01/.

> That said, I was still under the impression that this change could be
> discussed at the WG level and wouldn't block the charter...

Charters exist to define the scope of work and work products for the group. And
should the scope change or work products change, the charter is supposed to be
updated accordingly.

If something as significant as a 3339bis update is being considered by the WG,
it has to be in the charter. It cannot be done informally. To say otherwise is
in effect to say that charters are nonbinding and essentially meaningless.

> > I'm afraid this comment only reinforces my point about getting your
> > ducks in a row before proceeding: In his comments Bron was very clear
> > that this was a settled issue.

> > ...

> > If you disagree that this is a setttled issue - and it appears from what you've
> > said here that you do - then you need to confer with your colleagues in this
> > endeavor and decide on an approach.

> I don't think I completely agree with this inference. What's "settled"
> is always a function of what input we've received. Until a while ago,
> the signals from DISPATCH were clear: they wanted us to have nothing to
> do with RFC 3339 (because what we're doing here interests only a subset
> of implementations)

This sounds like possible mission creep to me.

> and the idea was that we would embed the entire
> instant format and publish a distinct RFC.

I once again refer you to what Bron has said about this. Your ducks are
not in a row.

> Now you've pointed out that
> referencing RFC 3339 would be a better idea, and while I agree that this
> is an important discussion to be had, I disagree that we need to block
> chartering the WG on this single decision.

This substantially mischaracterizes the situation.

> > A specification that attaches both metadata and other stuff to timestamps using
> > a completely different approach really doesn't help in any obvious way that I
> > can see. If the new charter opts to cite this as an input it needs to explain
> > how it's suoposed to be used.

> You asked about the ECMA specifications and I pointed you to them. The
> Temporal spec is not relevant to the work of the WG in any way except
> for the fact that it utilizes the format that we're trying to
> standardize here.

Again, other people seem to disagree.

I think this has reached, if not passed, the point of diminishing returns, so
I'm unlikely to respond further until new draft(s) are out along with
a new charter.

				Ned