Subject: Re: [dispatch] Proposed charter for extended date format

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 15 Apr 2021 02:00:09 +1000

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-extended/
> 
> 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
>   [email-masked]
> 
> 

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Apr 2021 13:37:43 -0400

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
<[email-masked]> wrote:

> This was discussed in the DISPATCH meeting at IETF110:
> https://datatracker.ietf.org/doc/minutes-110-dispatch/
> 
> * 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.
> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> --

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Apr 2021 19:42:23 +0200

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 <[email-masked]> wrote:
> 
> This was discussed in the DISPATCH meeting at IETF110: https://datatracker.ietf.org/doc/minutes-110-dispatch/ <https://datatracker.ietf.org/doc/minutes-110-dispatch/>
> 
>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>
>> 
>>   [email-masked] <mailto:[email-masked]>
>> 
>> 
> 
> --
>   [email-masked] <mailto:[email-masked]>
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Apr 2021 13:48:50 -0400

> Is it necessary for both the IETF and TC39 to standardize this?

Eliot,

See the note I just posted but to extract a quick comment for
those who are disinclined to read long notes...

You might reasonably has said:

	Is it necessary for both the IETF, ECMA TC39, and,
	perhaps unless they can be guaranteed to adopt the ECMA
	proposal, ISO, to standardize this?

IMO, good question.

    john

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 15 Apr 2021 04:00:06 +1000

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
> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> *Attachments:*
>  * signature.asc

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Apr 2021 21:28:46 +0200

I know that on IETF mailing lists it is unusual to discuss what the subject line says the discussion is about, but...

(1) I think we are discussing date/time formats here, not date formats.

(2) I think we are also discussing text string formats only, not formats in general.

If either of these assumptions is not true, I need to point to:

* Calendar dates: RFC8943 [1], which has a compact (binary) format for calendar dates in addition to the usual text-string one (based on RFC 3339, of course)

* Compact, complex (“extended”) datetimes: draft-bormann-cbor-time-tag [2], which has some elements of a date/time format that go beyond tags 0 (text-string, RFC3339) and 1 (compact, Posix) in RFC8949 [3].  Partially also inspired by [4].

What the latter needs next is a good TZDB [5] indexing mechanism (a.k.a. time zone names [6]); a compact form would be a bonus here again.

Just saying.

Grüße, Carsten

[1]: https://www.rfc-editor.org/rfc/rfc8943.html#section-1.1.1
[2]: https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#section-3.4
[3]: https://www.rfc-editor.org/rfc/rfc8949.html#name-standard-date-time-string
[4]: https://www.rfc-editor.org/rfc/rfc8575.html#section-3
[5]: https://data.iana.org/time-zones/tz-link.html
[6]: https://www.rfc-editor.org/rfc/rfc6557.html

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2021 18:45:45 -0400

>in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019).

Is there a way to find out what ISO 8801-2 says without spending
CHF 178?  I'm interested but at this point, not THAT interested.
(Arbitrage note, it's $225 or about CHF 207.)

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 15 Apr 2021 09:27:03 +0900

Hello John,

> (Arbitrage note, it's $225 or about CHF 207.)

I think you meant ISO 8601-2:2019
(https://www.iso.org/standard/70908.html). Sells for 23'496 Yen in 
Japan. No Japanese translation (yet), these are usually cheaper, and are 
often sold in groups in book form, which makes them quite reasonable. 
Listed at 75 pages. In the past, $1/CHF 1/100 Yen per page was a good 
estimate for ISO standard prices, but apparently they have jacked up 
their rates considerably. Unclear if they want their standards to 
actually be bought and used :-(.

Regards,    Martin.

---

From: "John R Levine" <[email-masked]>
Date: 14 Apr 2021 20:33:47 -0400

> I think you meant ISO 8601-2:2019

Yes, of course.

> (https://www.iso.org/standard/70908.html). Sells for 23'496 Yen in Japan.

Still a little out of my range.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Apr 2021 21:25:31 -0400

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
<[email-masked]> 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.
> 
> 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.
>>> 
>>> working group be charted from the discussion and the
>>> proposed charter text quoted below?
>>> 
>>> Thanks,
>>> 
>>> Bron.
>>> 
>>>> 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.
>>>> 
>>>> 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 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.
>>>> 
>>>> update to RFC3339 to allow larger than 4 digit signed
>>>> years, to enable representing times further into the past
>>>> and future.
>>>> 
>>>> group will be short-lived, and once the one or two
>>>> documents are published the working group will close down.
>>>> 
>>>> Milestones:
>>>> for extended datetimes. * July 2021: Submit the
>>>> serialisation document to the IESG.
>>>> 
>>>> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 15 Apr 2021 12:43:54 +1000

On Thu, Apr 15, 2021, at 11:25, John C Klensin wrote:
> standards developers actually work with each other. 

What a novel idea.

> That is
> standards is that there are so many to choose from.  

No shit.

> For many years, the IETF was excluded from that universe because we were
> considered immature 

... and this thread suggests that maybe we still are.

> and, even more important, of messing it up?

You may have noticed that this work was brought to the IETF by the people at ECMA TC39.  They also brought it to CalConnect who have a collaboration with ISO154.  Everyone in CalConnect agreed that it would be great it the IETF published the work as an extension to or replacement of RFC3339, so that it was generally available to more than just javascript as it would be if it was just TC39, and available to the public without paying, which it wouldn't be if it was just ISO publishing it.

Fast forward to actually bringing it here.  The first feedback was "don't replace 3339, because many places just need a point in time and we don't want to make it more complex to parse when used there".  Fine.

Then we were told to bring it to DISPATCH, so I helped the TC39 people do that.  I also attended the TC39 meeting where they were about to declare this work "done" and I asked them to hold for a few months, thinking that the IETF might actually be able to do this one fairly quickly.

I'm leaning towards the conclusion that the IETF is still constitutionally incapable of cooperating with other standards bodies given that experience that TC39 have had here.  Otherwise I've had a complete failure at persuasion, which is quite possible. 

Either way, unless the IETF takes a crap or gets off the pot on this topic pretty soon, TC39 is going to have to go ahead and standardise this work without our input, because they can't wait forever.

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 15 Apr 2021 12:45:25 +1000

> (2) I think we are also discussing text string formats only, not formats in general.

Yes - this was all discussed during the DISPATCH call, you are correct - those two points are the intent.

If the proposed charter is unclear on this then I would welcome suggested text changes.

Thanks,

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 15 Apr 2021 13:18:21 +1000

On Thu, Apr 15, 2021, at 08:45, John Levine wrote:
> It appears that John C Klensin  <[email-masked] <mailto:john-ietf%40jck.com>> said:

I have a draft of approximately what was published which is available to CalConnect members as part of our involvement with ISO, and I had a look through it just now to double-confirm my memory.

It says very little which is relevant to this work - most of the changes are around ways to specify ambiguous dates or period longer than a day (e.g. 2021-W15 is the week that we are currently in, 2021-34 represents the time period from March 1 to June 30 this year, XXXX-11-26 represents my birthday without specifying a year).

In particular, it doesn't do anything with timezones, calendar scales or calendar systems - it's Gregorian only.

So apart from the greater-than-4-digit year problem, there's nothing in ISO8601-2 which would benefit this work.

Bron.

---

From: Ujjwal Sharma <[email-masked]>
Date: Fri, 16 Apr 2021 15:07:53 +0530

Hi John!

> documents, thereby addressing the issue John Levine has raised.

I'm afraid I don't quite understand what you mean here? This *is* a
collaboration with ECMA TC39. We are TC39 delegates and the champions of
the Temporal proposal
(https://github.com/tc39/proposal-temporal/#champions) that deals with
the improvements around date-time handling in ECMAScript.

There is consensus among the TC39 delegates that this work should end up
in a standards body like the IETF before we proceed with it, as would be
evident from the discussions during plenary (notes at
https://github.com/tc39/notes/blob/master/meetings/2021-03/mar-9.md#temporal-for-stage-3,
search for "IETF" or my initials, "USA"), so this effort is already a
collaborative one between TC39 and IETF.

Regarding ISO, we have brought this to the notice of the folks working
on ISO8601 and CalConnect who seem to be happy with this generally, but
perhaps we could work to get them more in the loop if needed?

Cheers,
Ujjwal

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

Compilers Hacker, TC39 Delegate, Node.js Core Collaborator and Speaker

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Apr 2021 11:48:31 +0200

Hi Ujjwal,

> On 16 Apr 2021, at 11:37, Ujjwal Sharma <[email-masked]> wrote:
> 

That’s what I wanted to read.

Thanks,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Apr 2021 15:20:57 +0200

Just to follow up on this, in case there is any question or if anyone is keeping score, my question has been answered to my satisfaction and I support this work proceeding.

Eliot

> On 14 Apr 2021, at 19:42, Eliot Lear <lear=[email-masked]> wrote:
> 
> Signed PGP part
> Just one question:
> 
>> On 14 Apr 2021, at 18:00, Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Shane Carr <[email-masked]>
Date: Tue, 20 Apr 2021 10:39:56 -0500

I am looking forward to seeing the charter for this WG adopted, so that we
can work on the substantive issues in that forum.  What are the next steps
to adopt the charter?

On Tue, Apr 20, 2021 at 8:21 AM Eliot Lear <[email-masked]> wrote:

> Just to follow up on this, in case there is any question or if anyone is
> keeping score, my question has been answered to my satisfaction and I
> support this work proceeding.
>
> Eliot
>
> 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.
>
> 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.
>
> 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.
>
> 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:

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 30 Apr 2021 20:16:52 +0000

Hi all,

Thanks for the useful discussion, and thanks Bron for drafting a proposal charter text. The next steps are for me to request creation of a new mailing list (which will become the working group mailing list) and start the official chartering process. As a heads up, we will be looking for volunteers to chair this working group, so if you are willing to serve, or you have someone in mind who you believe would fit in the role, please let us know.
I’ll also reach out to ECMA TC39 chairs and ISO TC 154 to make sure the effort is coordinated.

Francesca

From: dispatch <[email-masked]> on behalf of Shane Carr <sffc=[email-masked]>
Date: Tuesday, 20 April 2021 at 18:14
To: Eliot Lear <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ujjwal Sharma <[email-masked]>, Eliot Lear <lear=[email-masked]>
Subject: Re: [dispatch] Proposed charter for extended date format

I am looking forward to seeing the charter for this WG adopted, so that we can work on the substantive issues in that forum.  What are the next steps to adopt the charter?

On Tue, Apr 20, 2021 at 8:21 AM Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:
Just to follow up on this, in case there is any question or if anyone is keeping score, my question has been answered to my satisfaction and I support this work proceeding.

Eliot

On 14 Apr 2021, at 19:42, Eliot Lear <lear=[email-masked]<mailto:lear=[email-masked]>> wrote:

Signed PGP part
Just one question:

Eliot

On 14 Apr 2021, at 18:00, Bron Gondwana <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Bron.

Cheers,

Bron.

Milestones:

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

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