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

ned+dispatch@mrochek.com Thu, 03 June 2021 14:05 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 1E8053A12EF for <dispatch@ietfa.amsl.com>; Thu, 3 Jun 2021 07:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 psZXKK2xYqFS for <dispatch@ietfa.amsl.com>; Thu, 3 Jun 2021 07:05:46 -0700 (PDT)
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 C0D673A12EC for <dispatch@ietf.org>; Thu, 3 Jun 2021 07:05:46 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZPZV6XN5C00IHB9@mauve.mrochek.com> for dispatch@ietf.org; Tue, 1 Jun 2021 11:13:10 -0700 (PDT)
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 <01RZMX49RI1S0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Tue, 1 Jun 2021 11:13:07 -0700 (PDT)
From: ned+dispatch@mrochek.com
Cc: "sedate@ietf.org" <sedate@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>
Message-id: <01RZPZV5ELIY0085YQ@mauve.mrochek.com>
Date: Tue, 01 Jun 2021 09:43:53 -0700
In-reply-to: "Your message dated Tue, 01 Jun 2021 14:45:54 +0000" <EEA84B36-BEA8-43F2-98F1-7C1BD817278F@ericsson.com>
References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <EEA84B36-BEA8-43F2-98F1-7C1BD817278F@ericsson.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/2uG8o0Ui0XNqN6d7Eg4YW_MCed0>
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: Thu, 03 Jun 2021 14:05:52 -0000

I have to object to a working being chartered with this remit.

The main problem is that the charter specifies that a variant of RFC 3339 is to
be embedded in this new specification, with no consideration given to the
alternate approach of incorporating either RFC 3339 or an RFC 3339bis by
reference.

This really isn't the time or place to get into all of the reasons why
incorporation by reference is a much better way to do this, so I'll simply note
that even if you ignore the confusion this can cause, having text in two places
that describes the same thing has proved to be a maintenance nightmare on many
previous occasions.

At an absolute minimum the choice of reference versus embedding should be left
to the working group, rather than being effectively chosen by the charter, and
this needs to be made very clear from the outset.

The charter also says that:

>     It is anticipated that this document would be a companion to RFC3339 rather
>     than a replacement, embedding an unaltered RFC3339 instant along with the
>     contextual data.

Except the current draft cited as a "good basis" for this work doesn't actually
do this. Rather, it preemptively extends RFC 3339 in not one but two ways:

(1) Years are extended to six digits
(2) Local offsets are extended to allow seconds and fractions of seconds.

Given the ability of the metadata (what the draft calls the "informative
suffix") to specify complex time zone rules, I question the need for (2), but
again, this is neither the time nor the place to get into these sorts of
details. The point is that this isn't "an unaltered RFC3339", and if this work
were to end up specifying this new format but not updating RFC 3339, we will
then have have two incompatible formats for basic timestamps.

Another problem is that the current draft makes a number of unnecessary changes
to the RFC 3339 ABNF, e.g., full-time becomes time-full, full-date becomes
date-full, date-fullyear becomes date-year, etc. Even granting that the new
names are in some sense "better", the problem is that other specifications can
and do reference specific rules in specifications like RFC 3339, and when you
change the the rule names, you complicate the update process for all of these
RFCs.

Finally, I concur with Carsten Bormann's point about noting that this is
exclusively a *text* format for date time values. Simply inserting the word
"text" in a couple of places would sufficient. And FWIW, I don't think extending
the current charter to cover binary formats is a good idea. If such a thing is
to be done, it should be accomplished via a recharter.

				Ned


> Hi all,

> (CC dispatch for information)

> The charter for the Sedate working group has passed the first phase and is now
> in external review. Additionally, the sedate mailing list has been created. Do
> go over there and subscribe if you are interested.

> Now is the time to let the IESG know of any comment you might have on the
> charter text.

> I am also looking for volunteers to chair the wg. It is ok to volunteer
> someone you think would be a good fit. I hope that, given the interest in this
> work, we will not have problems finding chairs, but as a reminder: please do
> consider volunteering if you support this work, as with no chairs there will be
> no working group.

> Please reply to this thread (dropping the dispatch mailing list), or send an
> email to the IESG (iesg@ietf.org), or directly to me with any comments on the
> charter, or volunteering as chair.

> Thanks,
> Francesca

> On 01/06/2021, 16:02, "Sedate on behalf of The IESG" <sedate-bounces@ietf.org on behalf of iesg-secretary@ietf.org> wrote:

>     A new IETF WG has been proposed in the Applications and Real-Time Area. The
>     IESG has not made any determination yet. The following draft charter was
>     submitted, and is provided for informational purposes only. Please send your
>     comments to the IESG mailing list (iesg@ietf.org) by 2021-06-11.

>     Serialising Extended Data About Times and Events (sedate)
>     -----------------------------------------------------------------------
>     Current status: Proposed WG

>     Chairs:
>       TBD

>     Assigned Area Director:
>       Francesca Palombini <francesca.palombini@ericsson.com>

>     Applications and Real-Time Area Directors:
>       Murray Kucherawy <superuser@gmail.com>
>       Francesca Palombini <francesca.palombini@ericsson.com>

>     Mailing list:
>       Address: sedate@ietf.org
>       To subscribe: https://www.ietf.org/mailman/listinfo/sedate
>       Archive: https://mailarchive.ietf.org/arch/browse/sedate/

>     Group page: https://datatracker.ietf.org/group/sedate/

>     Charter: https://datatracker.ietf.org/doc/charter-ietf-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 is necessary
>     to know the context in which the timepoint exists.

>     It is valuable to have a serialisation format that retains this context and
>     can reliably round-trip the additional context to systems that understand it,
>     via intermediate systems that only need to know about the instant in time.

>     The TC39 working group at ECMA have developed a format that is a good basis
>     for this work: draft-ryzokuken-datetime-extended.

>     It is anticipated that this document would be a companion to RFC3339 rather
>     than a replacement, embedding an unaltered RFC3339 instant along with the
>     contextual data.

>     It is also within scope for this working group to consider a minor update to
>     RFC3339 to allow larger than four-digit signed years, to enable representing
>     times further into the past and future.

>     It is anticipated that this working group will publish one or two documents
>     on the work mentioned above. After that, the working group will close down or
>     recharter.

>     The working group will coordinate with ECMA International TC39 and ISO TC154.

>     Milestones:

>       Dec 2021 - Submit extended date and time draft to the IESG for publication



>     --
>     Sedate mailing list
>     Sedate@ietf.org
>     https://www.ietf.org/mailman/listinfo/sedate

> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch