Re: [dispatch] Proposed charter for extended date format

[John C Klensin <[e-mail]>]

Bron,

I have heard that there is an alternate universe in which
standards developers actually work with each other.  That is
often with the goal of producing better work than either could
do separately or at least to avoid reinforcing the nasty comment
(known in both worlds) to the effect that the nice thing about
standards is that there are so many to choose from.  For many
years, the IETF was excluded from that universe because we were
considered immature and were pushing ideas (you know, like
packet switching and SMTP/822-based email) in which no one was
interested.  However, that period ended years ago and there
were, in that universe, many years in which collaborations were
possible and successful.  

In that universe, while some of those collaborations remain, it
has become difficult to establish new ones because the IETF has
concluded that working with other bodies on terms acceptable to
them is just not worth the trouble, at least unless they come to
us begging for such relationships.  Instead, we just announce to
them what we are doing, even if it is at variance with their
published standards, and expect them to adjust.

But, since we don't live in that universe (or at least I hope we
don't), why not work out a collaboration with ECMA TC39 [1] and,
ideally, a three-way one that includes ISO 154, and sort this
out together, vastly reducing both the chance of one body
standardizing something different from the rest of that world
and, even more important, of messing it up?  Another advantage
of such an approach is that it tends to drop any bars to
accessibility to each other's work in progress and other
documents, thereby addressing the issue John Levine has raised.

    john


--On Thursday, April 15, 2021 04:00 +1000 Bron Gondwana
<[e-mail]> wrote:

> I think the idea is that TC39 doesn't want to standardise
> something DIFFERENT than the rest of the world, so trying to
> get IETF to go first makes sense.  Failing that, TC39 can just
> do its own thing and hope the rest of the world follows, but
> that means it doesn't get a change to have as much outside
> review as the IETF process gives.
> 
> Bron.
> 
> On Thu, Apr 15, 2021, at 03:42, Eliot Lear wrote:
>> Just one question:
>> 
>> Is it necessary for *both* the IETF and TC39 to standardize
>> this?
>> 
>> Eliot
>> 
>>> On 14 Apr 2021, at 18:00, Bron Gondwana
>>> <[e-mail]> 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-e
>>>> xtended/
>>>> 
>>>> 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
>>>>   [e-mail]
>>>> 
>>>> 
>>> 
>>> --
>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>   [e-mail]
>>> 
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> *Attachments:*
>>  * signature.asc
> 
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>