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

Carsten Bormann <cabo@tzi.org> Fri, 04 June 2021 08:24 UTC

Return-Path: <cabo@tzi.org>
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 4E2023A2EC1; Fri, 4 Jun 2021 01:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no autolearn_force=no
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 YbLWfVavyOAI; Fri, 4 Jun 2021 01:24:12 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62DA3A2EBB; Fri, 4 Jun 2021 01:24:12 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FxG545nZzz2xFs; Fri, 4 Jun 2021 10:24:08 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <b85e1d9e-0376-1309-93f3-61172c7c5275@igalia.com>
Date: Fri, 04 Jun 2021 10:24:08 +0200
Cc: ned+sedate@mrochek.com, DISPATCH <dispatch@ietf.org>, sedate@ietf.org, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
X-Mao-Original-Outgoing-Id: 644487848.400376-c57c71df79dba13dcbf4725a2c0a06ef
Content-Transfer-Encoding: quoted-printable
Message-Id: <74F05F98-1733-4D38-BC89-0612EC788CBB@tzi.org>
References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <EEA84B36-BEA8-43F2-98F1-7C1BD817278F@ericsson.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <48D3CA53295C2C8C1045A23D@PSB> <01RZSYH3BXYS00IM2V@mauve.mrochek.com> <D99F554C-543A-4244-B871-26308F3EC393@tzi.org> <b85e1d9e-0376-1309-93f3-61172c7c5275@igalia.com>
To: Ujjwal Sharma <ryzokuken@igalia.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/oOSSLW_3G-YklKYa1cUlfTjMqeI>
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: Fri, 04 Jun 2021 08:24:16 -0000

>> I think there should be a really high burden of proof for anyone wanting to bring anything else that hasn’t been part of the version of ISO 8601 that was used at the time RFC 3339 was published.
>> (This should be in the charter, and the details can then be discussed in the WG.)
> 
> I agree here. There were parts of ISO 8601 that were excluded from RFC
> 3339 and we should adopt a similar strategy here, avoiding anything that
> seems to be excessive.
> 
> As a matter of fact, I chose to only include the expanded year format as
> well as sub-minute offsets because they were the only additions that
> seemed reasonable to me at the time.

I’m ignorant here: What are the use cases for sub-minute TZ offsets?
(And where in ISO 8601:2019 are they specified?)

> I'd be happy to consider further
> additions, but I agree that they should be well-justified to make the cut.

OK, so we do have some agreement here.

>> The Temporal proposal in TC39, however, is highly relevant.
>> However, it seems it is at stage 2...
> 
> This is no longer true, since Temporal has reached Stage 3 in the TC39
> process and many delegates are already working on implementing it in
> various engines. However, none of the implementations would ship
> unflagged until we move ahead with this work since the format might
> still be in flux...

The question is really whose work will be the leading one here.
Do we follow ECMA or does ECMA follow us?

Grüße, Carsten