Re: [dispatch] Proposed charter for extended date format

John C Klensin <john-ietf@jck.com> Wed, 14 April 2021 17:37 UTC

Return-Path: <john-ietf@jck.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 A60F13A18D9 for <dispatch@ietfa.amsl.com>; Wed, 14 Apr 2021 10:37:56 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 313TWuKcnhq6 for <dispatch@ietfa.amsl.com>; Wed, 14 Apr 2021 10:37:52 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E0A3A18D5 for <dispatch@ietf.org>; Wed, 14 Apr 2021 10:37:52 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lWjSX-000GuJ-54; Wed, 14 Apr 2021 13:37:49 -0400
Date: Wed, 14 Apr 2021 13:37:43 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bron Gondwana <brong@fastmailteam.com>
cc: dispatch@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>, Ujjwal Sharma <usharma@igalia.com>, Shane Carr <sffc@google.com>
Message-ID: <0C8FFDA77AF247414013590D@PSB>
In-Reply-To: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com>
References: <b654b280-00eb-4869-918f-5580347601ef@dogfood.fastmail.com> <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/yW5ny60GPHlHMn_VQnKJ8sa6g0w>
Subject: Re: [dispatch] Proposed charter for extended date format
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, 14 Apr 2021 17:37:57 -0000

Bron,

Without expressing a point of view on the merits of this
particular proposal described in this I-D or even about whether
a WG is created, I note with some concern the current discussion
on the ART list abut Date formats and what I gather have been
some issues with intervals and future times in calendaring (in
spite of the I-D excluding intervals from its scope).  I also
note that the I-D does not appear to show awareness of changes
in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019).


While it was probably appropriate when RFC 3339 was written 20
years ago, the interconnections between IETF work (and formats)
and formats emerging from, or being utilized in, work done
elsewhere that it seems to me that developing IETF-specific
extension or profiles requires much stronger justification than
I see in either the proposed charter or in
draft-ryzokuken-datetime-extended-01.  If anything, a new
document --especially if it proposes to replace 3339-- should be
much more tightly and explicitly bound to ISO 8601 (and the
current version of that spec) than 3339 was.

In the same context and as I have tried to say around the time
of the Dispatch meeting discussion, many specifications
developed in ECMA TCs move into ISO are are adopted into
International Standards unchanged.  Some don't.  It would be, at
least IMO, very unfortunate if we adopted a particular syntax
that then turned out to be incompatible with a future extension
or revision to ISO 8601.  Especially if we want to get out ahead
of the ISO Standard, one of the responsibilities of the WG
should be to work with the IAB to establish a liaison with the
relevant ISO TC or SC so that we can formally tell them what we
are doing (in conjunction or parallel with ECMA TC 39) and make
the case that the relevant standards should evolve in parallel
rather than diverging.

FWIW, I note that your 19 February note indicates that the
authors have decided on some strategy other than replacing 3339
and that a draft reflecting their revised proposal would appear
"soon".  According to the datatracker,
draft-ryzokuken-datetime-extended-01 (2021-01-22) is still
current. 

In addition, I note that the current I-D repeats the phrasing
"this document focuses on just one common usage, viz. timestamps
for Internet protocol events", copied from 3339.  At this point,
we know better than to believe in such a restriction (as the
discussion about 3339 versus 5322 dates, the CALDAV work, etc.,
show).  The WG should not be allowed to evaluate only the
implications for such timestamps as it considering the
consequences and possible tradeoffs in its work.

I want to stress that I am strongly in favor of work to better
define date-time formats in a clear and uniform way in the IETF.
If I were not, I would not have taken the time to write this
note.  However, precisely because of that, I'd like to see the
potential WG move forward on the strongest basis -- and the
clearest understanding of the scope and direction of the work--
as possible.  I think we are close, but the above issues suggest
that we are not quite there yet.

Two final notes/ asides: 

* We have two ART ADs.  Because the number of WGs in the Area
and how they interact affects both of them (and all of the rest
of us), is it appropriate for your question to be addressed to
Murray alone?

* As discussions of the TERM WG (or possible alternatives to it)
move forward, it is worth noting that the term "AD" is hurtful
and offensive to some people who understand its definition and
do not accept its implications.  There are many alternate terms
for describing positive offsets in the Gregorian calendar that
do not have those implications.  It is less of a problem (at
least from my personal perspective) but starting the range of
defined dates at year zero in that calendar can be considered
offensive too.

best,
    john


--On Thursday, April 15, 2021 02:00 +1000 Bron Gondwana
<brong@fastmailteam.com> wrote:

> This was discussed in the DISPATCH meeting at IETF110:
> https://datatracker.ietf.org/doc/minutes-110-dispatch/
> 
> The conclusion of the discussion was:
> 
> * Kirsty (chair): Sounds like there's general agreement that a
> working group is what's needed, we will take a final decision
> on the list and just confirm with Patrick as co-chair before
> officially dispatching as such. The link to the charter is on
> list too, please take a look and see if you think a BoF is
> needed as the next step or a WG can begin right away.
> 
> So Murray (AD), do you think we have enough to request a
> working group be charted from the discussion and the proposed
> charter text quoted below?
> 
> Thanks,
> 
> Bron.
> 
> On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote:
>> I've asked the chairs for space on the next dispatch agenda
>> to talk about dispatch for
>> 
>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-ext
>> ended/
>> 
>> The authors have taken on board the idea that we should
>> extract the "obsolete RFC3339" and either remove it entirely,
>> or separate it into a document which does nothing but update
>> RFC3339 with support for a wider range of year values.  There
>> will be an updated version of this draft soon.
>> 
>> The dispatch chairs also asked me for some proposed charter
>> text if we were to spin up a working group for this topic.
>> Here's that text.
>> 
>> Cheers,
>> 
>> Bron.
>> 
>> Serialising Extended Data About Times and Events (SEDATE)
>> ----
>> 
>> RFC3339 defines a format that can reliably express an instant
>> in time, either in UTC or in a local time along with the
>> offset against UTC, however datetime data often has
>> additional context, such as the timezone or calendar system
>> that was in use when that instant was recorded. Particularly
>> when using times for interval, recurrence, or offset
>> calculations, it's necessary to know the context in which the
>> timepoint exists.
>> 
>> It is valuable to have a serialisation format which retains
>> this context and can reliably round-trip the additional
>> context to systems which understand it, via intermediate
>> systems which only need to know about the instant in time.
>> 
>> The TC39 working group at ECMA have developed a format which
>> is a good basis for this work.
>> 
>> It is anticipated that this document would be a companion to
>> RFC3339 rather than a replacement, embedding an un-altered
>> RFC3339 instant along with the contextual data.
>> 
>> It is also within scope for this group to consider a minor
>> update to RFC3339 to allow larger than 4 digit signed years,
>> to enable representing times further into the past and future.
>> 
>> Once this work is done it is anticipated that this working
>> group will be short-lived, and once the one or two documents
>> are published the working group will close down.
>> 
>> Milestones:
>> * April 2021: Adopt draft describing a serialisation format
>> for extended datetimes. * July 2021: Submit the serialisation
>> document to the IESG.
>> 
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>> 
>> 
> 
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>