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

From: The IESG <[email-masked]>
Date: Tue, 01 Jun 2021 07:01:32 -0700

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 ([email-masked]) by 2021-06-11.

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

Chairs:
  TBD

Assigned Area Director:
  Francesca Palombini <[email-masked]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[email-masked]>
  Francesca Palombini <[email-masked]>

Mailing list:
  Address: [email-masked]
  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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Jun 2021 16:09:04 +0200

I support the creation of this group per our earlier discussion. This is 
a great example o ECMA/IETF cooperation.  Thanks for following through 
on it.

Eliot

On 01.06.21 16:01, The IESG wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Jun 2021 16:34:07 +0200

Thank you for making clear that this is about points in time (“datetime”), not “date” (see RFC 8943 for the difference).

The charter text could also make clear that this is about *text* formats for datetime.
Or maybe you do want to pull draft-ietf-cbor-time-tag from CBOR into this WG?  
(And RFC 8575, while you are at it.)
I don’t think ECMA TC39 would be very interested.  
I do think that over in CBOR we may be interested in the WG’s results, to pull in some of the results into the CBOR tag.

Grüße, Carsten

> On 2021-06-01, at 16:01, The IESG <[email-masked]> wrote:
> 
> -- 
> Sedate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sedate

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 1 Jun 2021 14:45:54 +0000

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 ([email-masked]), 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" <[email-masked] on behalf of [email-masked]> wrote:

    Chairs:
      TBD

    Assigned Area Director:

    Mailing list:
      Address: [email-masked]

    Milestones:

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Jun 2021 11:19:55 -0400

FWIW, I completely agree with Ned, especially wrt the issues of
the confusion and potential interoperability issues associated
with creating inconsistent standards and terminology.   To
further complicate things, RFC 3339 is based on on the 1988
version (or perhaps, given an additional reference that is not
cited, the 2000 one) of ISO 9601.   There is now a 2019 version
of ISO 8601, with the scope of the 1988 version extended and
split into two parts, the second specifically concerned with
extensions.  Any charter that proposes to tinker with RFC 3339,
potentially even including incorporating it by reference as Ned
suggests should have, as its first charter item, a careful
review of the current version of ISO 8601-1 and 8601-2 to
understand if, or how, they might affect the rest of the effort.
Failure to do so could lead us to three inconsistent ways of
doing things, not just two (which is one too many).

   john

--On Tuesday, June 1, 2021 09:43 -0700 [email-masked]
wrote:

> 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,
> 
>> 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.
> 
>> 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 ([email-masked]), or
>> directly to me with any comments on the charter, or
>> volunteering as chair.
> 
>> Thanks,
>> Francesca
> 
>> On 01/06/2021, 16:0䨳㸀㸀 ࠀ

---

From: [email-masked]
Date: Thu, 03 Jun 2021 12:35:38 -0700 (PDT)

I should have discussed ISO 8601 in my original response - my apologies for not
having done so. My (lame) excuse is that I have no good suggestions as to how to
handle it.

First, I take John's point that less is better, and having three specifications
with overlapping goals that are syntactically and semantically inconsistent
would be a really bad outcome.

That said, I'm very concerned by the fact that the revised ISO 8601
specifications are not freely available, and the cost to obtain them is nothing
short of outrageous: 336 CHF ($371 at today's exchange rate). These are also
hugely complex highly technical specifications, IMO incapable of being
summarized in any useful way. This means that anyone wishing to participate in
significant technical discussion involving them is going to need to purchase
copies. This represents a very significant burden to anyone wishing to
participate in the discussion without a corporate sponser willing to bear the
cost.

To be blunt, if the IETF decides that a review of ISO 8601 is required, either
as part of revising RFC 3339 or as part of developing the details of the
informative suffix, and is truly sincere about trying to lower the barriers to
participation in its technical discussions, some sort of arrangement needs to be
made with the ISO to make these documents available to WG participants at
reduced or no cost.

I also note that the current draft contains this requirement for specifications
defining additional suffix information:

*  The specification of valid keys MUST be available over the
   Internet and at no cost.

*  The specification MUST be in the public domain or available via a
   royalty-free license acceptable to the IETF and specified in the
   RFC.

*  The specification MUST be versioned, and each version of the
   specification MUST be numbered, dated, and stable.

These requirements would seem to make incorporation by reference of additional
information specified in ISO 8601-2 very difficult.

On the technical side of things, and ignoring for the moment the possibility of
ISO-8601 inspired changes in RFC 3339 - the only information suffix information
actually defined by the current draft is the ability to specify a time zone
rule:

   time-zone-char = ALPHA / "." / "_"
   time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".."
   time-zone-id   = time-zone-part *("/" time-zone-part)
   time-zone      = "[" time-zone-id "]"

(I note in passing that this ABNF appears to omit the possibility of there being
a tzidprefix as part of the time-zone-id.)

And as it happens, time zone rule specification is, AFAICT, addressed nowhere
in ISO 8601. So the question becomes one of whether ISO 8601 - part 2 in
particular - specifies anything that makes sense to put in the information
suffix.

And the answer to that is some things clearly qualify, some clearly do not,
and others... hard to say.

For example, since we're still describing an instant in time, things
like durations and sets of dates pretty clearly don't fit. Seasons, OTOH,
do fit.

But what about precision? (I don't think the way ISO 8601-2 specifies precision
is going to be particularly useful, but let's ignore that for now.) On the one
hand, this is about specifying an instant in time. On the other hand, things are
rarely that precise. And there's also the not-insignificant fact that precision
is really data, not metadata, so does it belong in the information suffix?

One takeaway here is that the specification needs to be a lot more precise
about what can go in the informative suffix and what can't. It seems to
me that an obvious dividing line is nothing in the suffix can move
the instant in time around, but beyond that things get a little sticky.

Beyond that, it seems clear that any review of ISO 8601-2 is going to get close
to, and may actually cross over into defining additional suffix information.
(Which, FWIW, I think would be a good thing - I think specifications defining
registries are almost always improved by specifying at least one initial entry
in the registry.) But this may be more work that the WG is prepared to do.

				Ned

---

From: Ujjwal Sharma <[email-masked]>
Date: Fri, 4 Jun 2021 03:45:33 +0530

Hey Ned!

On 01/06/2021 22.13, [email-masked] wrote:
> 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.

The draft is the way it is right now because the original idea was to
obsolete RFC 3339 in favor of it, and I haven't managed to set apart
enough time to properly update it.

> 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.

I don't have any opinions on the matter, but I agree with the principle.

> 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.

Right, I suppose we should change the charter... Is there someone who
strongly feels that the charter *should* mandate this?

> 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:
> 
> (2) Local offsets are extended to allow seconds and fractions of seconds.

I think your comment here highlights how the charter might be a tad
inconsistent with itself since above we talked about "a variant" of RFC
3339 being acceptable.

Talking more specifically about the two changes here, they were done
just to reflect the changes that have landed in ISO 8601 over the last
couple of years.

ECMA TC39 used ISO 8601 as the basis and added the extensions on top of
it, so I snuck these two changes in to make the final result consistent.
That said, I'd be fine to drop them if needed (or make a second draft
that does replace RFC 3339 and *just* has these two changes which we
could then reference in the draft with the extensions).

> 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.

This is just feedback for the draft, nothing to do with the charter. As
I mentioned previously, the original idea was to obsolete RFC 3339 and
also nobody else raised this concern before. I would be happy to revert
to the old ABNF, which would especially make sense if we split the draft
into two, one obsoleting RFC 3339 and the other referencing the former.

> 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.

I agree that binary formats are out of scope here. I'd be happy if the
charter were updated to reflect that.

Hope I've managed to address your concerns,
Best,
Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 01:01:12 +0200

> participate in the discussion without a corporate sponser willing to bear the

To be blunt, I’d suggest we (almost) entirely ignore ISO 8601:2019.

My spies tell me ISO 8601-2:2019 was created as a container for a number of the ideas that aren’t so relevant for text-based date-times (uncertainties? Spring Northern Hemisphere?  Quadrimesters?).
ISO 8601-1:2019 seems to have 6-digit years (±NNNNNN, so it’s +002021-06-03T22:44:37.095927Z here right now), which we should adopt (but certainly not century or decade references and lots of other innovations that are great for library managers but not so much on the Internet).

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.)

The Temporal proposal in TC39, however, is highly relevant.
However, it seems it is at stage 2...

Grüße, Carsten

---

From: Ujjwal Sharma <[email-masked]>
Date: Fri, 4 Jun 2021 11:41:51 +0530

Hey Carsten!

> (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'd be happy to consider further
additions, but I agree that they should be well-justified to make the cut.

> 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...

Hope this helps,
Best,
Ujjwal

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 10:24:08 +0200

> 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

OK, so we do have some agreement here.

> unflagged until we move ahead with this work since the format might

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

Grüße, Carsten

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 07 Jun 2021 20:40:26 +1000

Sorry for the delay in replying on all this. I'm going to try to address all the points on this one email.

> (And where in ISO 8601:2019 are they specified?)

I'm not sure about this one either.

I don't think we need to extend RFC3339 for this other than maybe the >4 digit years, but I'd be happy to discuss that as part of working on the document.

> Do we follow ECMA or does ECMA follow us?

Well... we've taken a good many months since ECMA first approached us, during which time of course they couldn't totally just wait.  So I expect it comes down to something along the lines of "we're mostly following ECMA on the data model, but we have more leeway on the representation".  In particular we need to be able to round-trip the fields which ECMA needs to round trip in order to be useful to them.

But the whole point of ECMA approaching IETF is to ensure that everyone does the same thing, and that's going to be around documenting the edge cases and nailing down the format and the exact byte (character, anyway) representations of everything.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 7 Jun 2021 20:06:05 +0530

Hey Bron, Carsten!

On 07/06/2021 16.10, Bron Gondwana wrote:
> I don't think we need to extend RFC3339 for this other than maybe the >4
> digit years, but I'd be happy to discuss that as part of working on the
> document.

I'm really sorry for the confusion, you're both right. I rechecked and
this doesn't come from ISO 8601, but is actually an addition by us (ECMA
TC39) to make sure all historic time zones can have an offset without
any mismatch between the IANA zone metadata and the offset. For a more
in-depth discussion on this, check out
https://github.com/tc39/proposal-temporal/issues/935.

That said, I agree with Bron here: we can talk about this change in more
detail within the WG and if we decide against keeping this, I'll make
sure ECMA makes the necessary changes.

> Well... we've taken a good many months since ECMA first approached us,
> during which time of course they couldn't totally just wait.  So I
> expect it comes down to something along the lines of "we're mostly
> following ECMA on the data model, but we have more leeway on the
> representation".  In particular we need to be able to round-trip the
> fields which ECMA needs to round trip in order to be useful to them.
> 
> But the whole point of ECMA approaching IETF is to ensure that everyone
> does the same thing, and that's going to be around documenting the edge
> cases and nailing down the format and the exact byte (character, anyway)
> representations of everything.

Exactly. ECMAScript implementations won't ship this unflagged before
there is consensus on the format. If we decide to make any changes to
the representation, I'll make sure that the changes carry over to ECMA.

Hope this helps unblock us from chartering,
Ujjwal