Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (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:

    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

    -- 
    Sedate mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sedate

---

From: [email-masked]
Date: Tue, 01 Jun 2021 09:43:53 -0700 (PDT)

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.

>     than a replacement, embedding an unaltered RFC3339 instant along with the

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

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

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

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:

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

> alternate approach of incorporating either RFC 3339 or an RFC 3339bis by

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.

> that describes the same thing has proved to be a maintenance nightmare on many

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

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

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

> change the the rule names, you complicate the update process for all of these

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.

> 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:44:31 +1000

> alternate approach of incorporating either RFC 3339 or an RFC 3339bis by

I take a lot of responsibility for this - and it's this way *because* of the feedback in DISPATCH last time, which was "don't try messing with RFC3339".  But I think maybe you also looked at the draft as it was proposed back then because - again - I didn't push hard enough to have an actual draft uploaded which specified basically that this would look something like:

"RFC3339{bis}-point-in-time{extended context}" (exact encoding TBD)

And that we wouldn't mess with 3339 OR we would BIS 3339 for the first part, and produce another document which referenced RFC3339 or RFC3339bis as the definition for the point-in-time part.

This is how I understand the goals of this intended group to be - and if that's not adequately represented in the proposed charter text then I would welcome clarifying edits!

Thanks,

Bron.

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

---

From: [email-masked]
Date: Mon, 07 Jun 2021 06:19:17 -0700 (PDT)

> I take a lot of responsibility for this - and it's this way *because* of the
> feedback in DISPATCH last time, which was "don't try messing with RFC3339".  But
> I think maybe you also looked at the draft as it was proposed back then because
> - again - I didn't push hard enough to have an actual draft uploaded which
> specified basically that this would look something like:

I looked at the draft that cited in the charter as being, and I quote, "A good
basis for this work." Nothing more, nothing less.

What you are now saying is that wasn't true. And more generally, you asked
people to spend time reviewing an obsolete version of the proposed work.

This is a good time to point out that the IETF depends on large amounts or work
being undertaken by volunteers, corporate sponsored at best, but in many cases,
aside from an occasional mention in an acknowledgements section, entirely
uncompensated. 

There has been a lot of talk recently about how to make the IETF more welcoming
to newcomers, as well as how to retain people after the work that attracted them
to the IETF is finished. 

I'm afraid I can think of few things more disheartening than a demonstrable lack
of concern for wasting people's time. Indeed, in a curious way it's more
disrespectful than a direct personal attack, since at least when someone attacks
you it's clear that they care about whatever it is you said or did.

In any case, in the future, when you propose a charter, please try and make sure
it accurately represents the work you want to do.

> And that we wouldn't mess with 3339 OR we would BIS 3339 for the first part,
> and produce another document which referenced RFC3339 or RFC3339bis as the
> definition for the point-in-time part.

> This is how I understand the goals of this intended group to be - and if
> that's not adequately represented in the proposed charter text then I would
> welcome clarifying edits!

We are way past this being a matter that can be resolved by a few edits.

First, the current charter proposal needs to be withdrawn. You then need to
produce two drafts:

(1) RFC 3339bis 
(2) Extended context

You then may want to get some preliminary review of these documents, to make
sure they track with your intended goals. Or not - it may be that the people
working on these specifications have a clear shared understanding of what's
needed.

Once this is done a new charter needs to be submitted that describes the work to
be done, with these two new drafts as a starting point. Given the wide use of
RFC 3339, it needs to be very specific about what is or isn't in scope for the
revision of that specification.

As I said in a previous comment, I have no idea what, if anything, to do about
the revised versions of ISO 8601, so I leave that to you to figure out. 

That said, some of the subsequent comments about ECMA International TC39 and ISO
TC154, as well as statements like "Temporal proposal having reached stage 3" and
"delegates are already working on implementing it in various engines" seem to me
to be even more of a cause for concern. If this work really is as advanced as
these statements seem to imply, and is in any way constraining on what we're
doing here, then the WG needs access to these specifications.

In case it isn't clear, the situation I want to avoid is where someone in the WG
comes up with some proposal, only to be told, "Sorry, that's not the TC39 way,
and no, I don't have anything to show you what that way actually is."

I think that covers it.

				Ned

---

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

Hi Ned!

> revision of that specification.

Pardon my relative inexperience with IETF, but I suppose by RFC 3339bis
you mean "a document detailing the updates to RFC 3339 but not the
extension format". This document already exists at
https://github.com/ryzokuken/draft-ryzokuken-datetime-updated (source),
https://ryzokuken.dev/draft-ryzokuken-datetime-updated/documents/rfc-3339.html
(rendered) and
https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/. The
(relatively) smaller diff can be found at
https://github.com/ryzokuken/draft-ryzokuken-datetime-updated/compare/original...main
(look in the sources folder).

The draft that you reviewed is just a version of this RFC 3339bis that
also includes the extension format. As mentioned before, this was done
because there was not enough clarity around how we could best get
consensus around the format. If you prefer that the extension format
refer to (and not extend) the RFC 3339bis, then that would work just
fine and I suppose we could discuss that in great detail within the WG
(personally, I'd be happy either way).

> and no, I don't have anything to show you what that way actually is."

You are already aware of the situation around ISO 8601, but all the ECMA
TC39 specs and proposals are published freely on the internet.
Everything relevant to this work is contained in the "Temporal" proposal
which is published at https://tc39.es/proposal-temporal/.

Hope this clarifies everything, feel free to ask for further clarification,
Ujjwal

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jun 2021 14:02:09 -0400

Bron,

I largely (almost completely) agree with Ned's comments,
especially about moving targets and people's time, but let me
add one thing.

--On Monday, June 7, 2021 06:19 -0700 [email-masked]
wrote:

> That said, some of the subsequent comments about ECMA
> International TC39 and ISO TC154, as well as statements like
> "Temporal proposal having reached stage 3" and "delegates are
> already working on implementing it in various engines" seem to
> me to be even more of a cause for concern. If this work really
> is as advanced as these statements seem to imply, and is in
> any way constraining on what we're doing here, then the WG
> needs access to these specifications.
 
> In case it isn't clear, the situation I want to avoid is where
> someone in the WG comes up with some proposal, only to be
> told, "Sorry, that's not the TC39 way, and no, I don't have
> anything to show you what that way actually is."

Having parallel, unsynchronized, efforts among standards bodies
with very different work styles and keeping them coordinated is
extremely difficult -- not impossible, but difficult and
requiring significant energy.  Agreements that establish clear
"who does what" boundaries and that are accepted by all SDO
parties can help a lot, sometimes even solve the potential
problems, but I have see no sign of such clear and agreed
boundaries in anything I have seen so far of this WG proposal.
Without either such boundaries or very significant coordination,
the odds are very high of ending up with either the situation
Ned describes above or the closely related one of ending up with
two standards that conflict, perhaps only in minor ways but
sufficient to confuse everyone (IIR, Ned mentioned that earlier
too).

So I would like to see something else considered.  Is it
possible to consider, and explain clearly (and without the
specific details of an extension specification or 3339 update)
to both the IETF and to the relevant ECMA and ISO groups, what
we (the Internet and/or the IETF) need in dates and times that
is not covered by ISO 8601-1:2019 or ISO 8601-2:2019 (let's just
ignore 3339 for the moment)?  If the goals of this proposed WG
are understood well enough, it ought to be possible to describe
those requirements in a succinct and clear way without needing a
WG.  If they are not, then, IMO, a WG charter is premature.
With such a description in hand, it becomes possible to ask
another question, which is whether such work is best done in the
IETF (and, if so why) or whether it should simply be developed
and processed in ECMA and ISO, via a New Work Item for either an
Amendment or something that might evolve into 8601-3 as
appropriate?  Presumably that would come with arrangements for
IETF participants  to provide input who are not already involved
in 8601* via some national member body, ECMA, or some other
organization.

If that sort of approach made sense, the next step would be to
produce a 3339bis that was just a summary or profile of 8601*,
working with ISO to quote sufficiently from their standards to
make 3339bis essentially self-contained.

I'm not sure that approach is the right answer but, noting that
RFC 3339 is about conventions for use on the network but is not,
itself, a network protocol or piece of network engineering and
that ISO 8601* has far, far, broader uses and applications than
the Internet, I think it should be examined before we either try
to do that coordination work or decide we can proceed on
informal relationships and otherwise without it.

best,
   john\

---

From: [email-masked]
Date: Tue, 08 Jun 2021 05:30:42 -0700 (PDT)

> (look in the sources folder).

First, this document was cited nowhere in the proposed charter. If the intent is
to use this as a basis for the 3339bis work, it should have been.

Second, this document illustrates very nicely why the charter needs to nail down
what is and isnt't allowed in a potential 3339bis: Despite its limited scope it
retains the completely gratuitous changes to the 3339 ABNF the other document
had. As I pointed out in my original review, it is essential that the ABNF
remain as stable as possible, in order to prevent breakage in other documents
that reference specific productions. If you want to see how this is done I
suggest looking at how RFC 6532 did it for the productions in RFC 5322.

Third, I'm intentionally ignoring the issue of what changes, if
any, are actually needed. That's for the WG to decide, and I really don't want
to derail getting the charter done in order to discuss the appropriateness
of fractional seconds in time offsets. The charter should specify
the scope of the allowed changes and leave it at that.

> (personally, I'd be happy either way).

I'm afraid this comment only reinforces my point about getting your
ducks in a row before proceeding: In his comments Bron was very clear
that this was a settled issue. He said:

If you disagree that this is a setttled issue - and it appears from what you've
said here that you do - then you need to confer with your colleagues in this
endeavor and decide on an approach.

I will also note that this is not now and never had been a question of what
I "prefer". It's a question of using an approach that experience has shown
to work versus one that experience has shown ... doesn't.

> which is published at https://tc39.es/proposal-temporal/.

A specification that attaches both metadata and other stuff to timestamps using
a completely different approach really doesn't help in any obvious way that I
can see. If the new charter opts to cite this as an input it needs to explain
how it's suoposed to be used.

> Hope this clarifies everything, feel free to ask for further clarification,

I'm afraid what it does is confirm most, if not all, of my objections were
on point.

				Ned

---

From: Ujjwal Sharma <[email-masked]>
Date: Wed, 9 Jun 2021 00:34:06 +0530

Hey Ned!

> suggest looking at how RFC 6532 did it for the productions in RFC 5322.

As I mentioned previously, your review was the first time it was raised
to me and I understand the concern completely. As a matter of fact, I
already submitted a new version of the draft to fix that:
https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/01/.

That said, I was still under the impression that this change could be
discussed at the WG level and wouldn't block the charter...

> the scope of the allowed changes and leave it at that.

That's great! I agree.

> that this was a settled issue. He sai> ...

I don't think I completely agree with this inference. What's "settled"
is always a function of what input we've received. Until a while ago,
the signals from DISPATCH were clear: they wanted us to have nothing to
do with RFC 3339 (because what we're doing here interests only a subset
of implementations) and the idea was that we would embed the entire
instant format and publish a distinct RFC. Now you've pointed out that
referencing RFC 3339 would be a better idea, and while I agree that this
is an important discussion to be had, I disagree that we need to block
chartering the WG on this single decision.

> how it's suoposed to be used.

You asked about the ECMA specifications and I pointed you to them. The
Temporal spec is not relevant to the work of the WG in any way except
for the fact that it utilizes the format that we're trying to
standardize here.

Best,
Ujjwal

---

From: [email-masked]
Date: Wed, 09 Jun 2021 07:25:50 -0700 (PDT)

> discussed at the WG level and wouldn't block the charter...

Charters exist to define the scope of work and work products for the group. And
should the scope change or work products change, the charter is supposed to be
updated accordingly.

If something as significant as a 3339bis update is being considered by the WG,
it has to be in the charter. It cannot be done informally. To say otherwise is
in effect to say that charters are nonbinding and essentially meaningless.

> > that this was a settled issue.

> > ...

> of implementations)

This sounds like possible mission creep to me.

> and the idea was that we would embed the entire
> instant format and publish a distinct RFC.

I once again refer you to what Bron has said about this. Your ducks are
not in a row.

> Now you've pointed out that

This substantially mischaracterizes the situation.

> for the fact that it utilizes the format that we're trying to

Again, other people seem to disagree.

I think this has reached, if not passed, the point of diminishing returns, so
I'm unlikely to respond further until new draft(s) are out along with
a new charter.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Jun 2021 13:13:47 -0400

--On Wednesday, June 9, 2021 00:34 +0530 Ujjwal Sharma
<[email-masked]> wrote:

>> Second, this document illustrates very nicely why the charter
>> needs to nail down what is and isnt't allowed in a potential
>> 3339bis: Despite its limited scope it retains the completely
>> gratuitous changes to the 3339 ABNF the other document had.
>> As I pointed out in my original review, it is essential that
>> the ABNF remain as stable as possible, in order to prevent
>> breakage in other documents that reference specific
>> productions. If you want to see how this is done I suggest
>> looking at how RFC 6532 did it for the productions in RFC
>> 5322.
> 
> As I mentioned previously, your review was the first time it
> was raised to me and I understand the concern completely. As a
> matter of fact, I already submitted a new version of the draft
> to fix that:
> That said, I was still under the impression that this change
> could be discussed at the WG level and wouldn't block the
> charter...
>...

Ujjwal,

Drawing inspiration from Ned's remarks, some off-list
discussions, and a sense that the people you probably see as
resisting and you and your colleagues are not communicating very
well, let me see if I can explain the situation in a different
way and make a suggestion.

(1) The timestamp format specified in RFC 3339 is very widely
deployed and used, both in support of IETF standards and outside
them.  Changing it would be a big deal, very disruptive, and
should be undertaken only with clear explanation and strong
justification as to why that is necessary and worth the risks.
We have had a few experiences in the IETF in which documents
that were supposedly just intended to update and replace others,
making no or tightly focused substantive changes, inadvertently
introduced errors and more substantive changes.  We've caught
more, but not all, of those before or during IETF Last Call, but
considerable energy had been spent by then.  If those risks are
necessary, an explanation and justification for taking them has
not, as far as I can tell, appeared. And "don't touch 3339" does
not mean "copy a good deal of text out of 3339, with or without
slight modifications" either.

(2) RFC 3339 is a profile of ISO 8601:1998.  Other than the
references being out of date because 8601 has been updated now
consists of two parts, no information has been presented so far
that 3339 has become inconsistent with ISO 8601-1:2019.  If it
is, we have another problem, but there is no indication in
either your draft or the draft charter as to what it is and what
you propose doing about it.  In any event, it is probably a
different task from the extension.  

(3) I may still be confused about this but if what you are
proposing is a pure extension that does not conflict with or
alter any of RFC 3339, ISO 8601-1:2019, ISO 8601-2:2019, or
ongoing work in ECMA or ISO/ TC 154, then the charter should say
that explicitly and the I-D should make that clear, explain why
it is needed, and concentrate on the extension.  Ideally, if
this proposal reflects new (since 3339 was written) work in the
ECMA and ISO groups, it should make that clear and should be
written much the way 3339 was written: as a profile of that work
with sufficient discussion and examples to be usable without the
reader needing to read and understand the ISO standards.  If it
is actually a clean extension to the current ISO standards and
RFC 3339, the document should not need to repeat or paraphrase
RFC 3339 in any way.  It is likely to need to reference it but
the only necessary update to RFC 3339 should be to note that
readers of 3339 might want to look at the new spec and under
what circumstances plus _maybe_ supplying updated references it
is is possible to assert that the updates don't change anything
because there have been no substantive changes since 1988 in the
ISO documents on which 3339 depends that would affect 3339's
validity as a profile.

I may have been confused and probably was but I came away from
the DISPATCH discussion believing that the plan was to do (3)
above and only that, and that everything else was about the
details.  No charter provisions that would allow the WG to
decide it was appropriate to alter 3339 (especially the
timestamp format) without coming back to the community and
getting consensus about that plan.  And, if the extension is
going to be inconsistent with either 3339 or ISO 8601-*:2019 in
any way (i.e., not a fully compatible add-on to either one),
then I think (and would have said during DISPATCH had it seemed
necessary) that needs to be spelled out and the charter and get
rough community consensus.

With the understanding that the above is nothing but an attempt
to summarize recent discussions rather than saying anything new,
I hope it helps.

best, 
   john