►
From YouTube: IETF111-SEDATE-20210727-1900
Description
SEDATE meeting session at IETF111
2021/07/27 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
As
you
can
see,
I
updated
part
of
the
date,
but
not
all
of
it.
So
the
date
on
these
slides
is
wrong,
which
I
guess
is
probably
about
the
right
thing
for
this
working
group.
So
there
we
go
get
it
kicking
us
off
to
a
great
start.
A
So
please
read
those
if
you're
not
aware
of
them
with
that
said,
this
is
our
agenda
for
what
we're
going
to
do
today.
First,
an
introduction
and
kind
of
a
background
how
we
got
here
any
and
gender
bashing.
So
if
you
have
anything
else,
you
want
to
speak
about
other
than
the
one
document
we
have
here.
A
Please,
let
us
know
at
this
stage
milestone
and
review
for
the
charter
on
this
working
group
and
any
other
business
that
comes
up
mark
has
kindly
offered
to
transcribe
to
the
cody
md
my
co-chair
and,
and
I
think
between
that
and
given
how
small
the
group
is,
please
feel
free
to
chat
pretty
much
anytime.
I
think
this
while
we'll.
Let
us
know
whether
he'd
prefer
to
take
questions
as
we
go
or
at
the
end.
A
A
So
some
quick
background
on
how
we
got
here.
Oh
yes,
first
instruction,
here's
his
the
background
on
us
he's.
The
two
chairs
are
feel
free
to
contact
us
at
any
time.
Email
address,
sedate,
hyphen
chairs
at
iatf.org
will
reach
both
of
us.
Otherwise,
you
can
find
our
email
addresses
directly
in
the
data
tracker
francesca
is
our
lovely
area
director
and
is
very
helpful
for
any
questions
about
us.
A
A
A
A
This
is
an
overview
of
our
charter.
What
our
goals
are
and
are
not.
We
will
publish
a
text,
serialization
format
for
context
around
the
time
stamp,
which
is
a
companion
to
rfc
3339,
embeds
rsc3339
data
and
when
it
makes
it
easy
to
pass
just
that
date
time
out
of
it
and
is
able
to
round
trip
through
intermediate
systems,
we'll
coordinate
with
ecma
tc39
and
iso
tc154,
which
are
the
groups
that
are
also
working
on
these
things.
To
ensure
that
the
work
remains
a
strict
extension
of
iso
8601,
which
was
recently
revised.
A
But
everything
we've
seen
seems
to
suggest
that
there's
no
collisions
at
the
moment
and
we
are
coordinating
with
people
from
those
groups.
We
will
not
make
any
updates
to
rc339
without
recharging
this
working
group
and
we
will
not
destabilize
existing
ietf
protocols
or
the
internet
generally
and
that's
copy
pasted
straight
from
our
charter.
A
This
is
the
document
it
wasn't
formally
adopted
as
part
of
the
chartering
process,
so
the
first
order
of
business
after
it's
been
presented
is
going
to
formally
adopt
the
document.
If
anyone
wants
to
speak
to
that
before
we
start
looking
at
the
documents
feel
free
to
hop
in
the
queue
final
call,
always
we'll
go
to
the
mailing
list,
of
course,
for
the
adoption,
and
given
that
it's
our
one
order
of
business,
I
expect
that
will
go
fairly
smoothly,
but
yeah.
If
you
do
have
any
objections
or
any
questions
about
the
document.
A
A
B
Wait,
can
you
can
you
die.
A
Would
that
work?
I
can
let
you
share
your
screen
or
you
can
ask
for
slide
control,
I
believe,
and
then
you
can
control
these
slides
that
are
already
loaded
in.
So
it's
up
to
you.
B
A
Fantastic
then
that
sounds
good
to
me.
I
will
unshare
the
slides.
If
you
request
screen
sharing,
there
should
be
a
button
in
your
top
left
hand
of
your
screen
yep,
and
then
I
can
grant
you
screen
sharing
excellent
I'll
pop
myself,
a
mute
while
you're
talking.
B
You
can
see
your
slides,
oh
okay,
perfect,
sorry,
hello
and
thank
you
ron
for
for
the
awesome
introduction
and
I
just
patched
together
a
small
set
of
slides,
let's
get
through
these,
and
we
can
get
into
the
discussion
more.
So
just
a
little
bit
of
context,
I
immediately
nice
to
meet
you
if
you
haven't
yet,
and
you
can
find
me
on
the
internet
at
rise
of
cooking.
B
So
if
you
want
to
shout
at
me
anyway,
that's
what
you're,
looking
at
just
to
remind
you
where
we're
coming
from,
I
am
a
delegate
for
ecma
tc39.
B
The
ecma
tc39
is
for
some
background
the
committee,
the
standards
committee
that
standardizes
ecmascript
or
javascript
there's
a
bunch
of
really
cool
members
who
contribute
different
viewpoints
to
this
committee.
B
Specifically,
I
also
belong
to
a
smaller
group
called
the
temporal
champions
group
who
are
tasked
with
standardizing
a
a
replacement
for
the
javascript
date
object
and
and
hopefully
improve
it
for
the
better
and
so
we're
building
a
more
modern
ergonomic
api
for
building
data
in
time
applications.
That's
what
the
what
this
all
comes
out
of
and
yeah
the
group
is-
is
composed
of
a
very
diverse
set
of
individuals.
So
the
the
history
I
mean
braun
tried
to
give
a
good
background.
B
But
from
from
my
end,
the
history
starts
where
we
have
a
number
of
non-standard
zone:
timestamp
formats
right,
they're,
they're,
all
over
the
internet
and
they're,
not
really
standardized,
there's
a
format
that
just
you
know,
adds
at
some
white
space
and
then
does
the
time
zone
and
then
there's
the
brackets
and
there's
there's
just
no
consensus
there
and
temporal
needs
to
take
things
a
bit
further
and
we
need
to
add
calendars
to
the
mix
and
this
becomes
complicated
because
there's
no
standardized
format
to
build
on
top
of
right.
B
There's,
just
good
old
3339.
B
B
You
can
see
those
slides
over
here,
but
all
in
all,
all
the
follow-up
discussions
led
to
this
working
group
that
we're
in
right
now
so
sedate
comes
out
of
this
effort
to
to
add
extensions
and
more
metadata
to
timestamp
formats.
B
What
has
changed
since
the
time
that
we
touched
base
on
this
last
time?
So
initially
we
we
came
with
a
very
ambitious
proposals
proposal
and-
and
we
not
only
tried
to
standardize
the
annotation
format,
but
we
tried
to
sort
of
modernize
339,
as
it
was
remove.
Some
of
the
things
that
we
thought
at
the
time
were
not
in
sync,
with
the
current
state
of
iso
8601
and
add
a
bunch
of
cool
things
with
we've
reached
more
realistic
goals.
B
At
this
point,
I
think
it
was
a
good
idea
to
to
do
not
make
any
radical
changes
to
the
underlying
format
that
so
many
people
depend
on
and
instead
build
on
top
of
that
as
a
sort
of
an
extension
format.
So
that's
where
we
are
right
now
so
yeah
we
build
on
top
of
3.9
and
updates
to
the
core
instant.
You
know
time.
Stamp
format
is
out
of
scope:
tempo
in
dc39,
lingo
tempo
is
stage
3,
which
means
that
implementations
are
now
ongoing.
B
They,
the
design
of
the
api
that
we
built,
is
finalized
and
you
know
different
browsers
or
our
ship
are
starting
to
implement
the
proposal,
that's
where
we
are
at
kc
39
sites,
and
then
we
are
in
in
in
the
sedate
when
we
are
in
conversations
with
isil
for
for
a
liaison
agreement,
and
you
know
getting
things
going
on
that
front.
B
The
draft
that
that
I,
that
was
going
to
before
which
we
are
hoping
to
adopt,
underwent
another
round
of
reviews.
So
it's
it's
changed
it's
cleaner
now,
so
hopefully
it
will
be
better,
but
yeah.
All
further
reviews
would
be
really
appreciated.
So
this
is
the
the
good
old
format
that
we're
talking
about
right.
This
is
our
instance
look
on
on
the
internet
and
this
is
sort
of
the
other
format
that
that
we
see
a
lot.
B
The
text
breaking
this
way,
but
if
you
see
here
at
the
at
the
end
of
this
instant
there's
an
additional
europe
slash
london,
you
know
annotation,
and
this
is
supposed
to
mean
that
you
know
this
particular
time
zone
is
sorry.
This
particular
time
stamp
is
within
the
context
of
this
human
time
zone,
and
this
is
this
is
what
we've
been
planning.
So
apart
from
this
annotation
that
we
just
talked
about,
there
can
be
another
annotation
for
the
time,
sorry
for
the
calendar
in
this
case
hebrew.
B
So
why
is
this
context
useful?
Why
do
we
do
this
at
all?
What
what's
wrong
with
or
why
are
the
the
existing
formats?
Not
sufficient
for
us
is
that
operations
that
are
done
on
any
instant
relies
on
this
context
right
the
the
current
model,
where
there
is
no
context,
it
assumes
one
of
two
things:
it
assumes
that
there
is
no
no
information
at
all,
which
is
bad
because
you
know
there
is
information.
It's
just
you
know
it's,
it's
not
conveyed,
and
it's
not
being
it's.
B
It's
not
traveling
between
the
different
programs
that
are
that,
are
you
know,
communicating
this
information
or
it
assumes
that
the
the
time
zone
in
this
case
would
be
you
you
see
or
the
calendar
is,
is
the
so-called
iso
calendar,
which
is
the
proleptic
oriented
calendar,
which
is
worse.
It
is
worse
because
you
know
utc
is
not
a
human
time,
so
nobody
lives
in
utc.
You
could
live
in
europe,
reykjavik
or
you
could
be
living
in
europe,
london,
but
that's
not
utc.
B
It's
it's
a
different
time
zone
and
it
can
change,
and
you
know,
do
different
things
and
the
iso
calendar
is
not
something
that
people
use
in
their
sort
of
daily
lives
either
it's
people
most
commonly
use
the
the
gregorian
calendar,
but
you
know
other
calendars
too,
of
course,
so
so
this
can
be
bad
in
many
ways
and
I
think
the
best
ideas
to
specify
a
a
mechanism
for
implementations
to
convey
this
information
and
to
you
know
transport
it
between
each
other.
B
So,
for
example,
if
I
take
the
time
instant
right
now-
and
I
add
five
hours
to
it,
right
that
that
operation
depends
on
which
time
zone
I'm
in
you
know
if
it's
1
pm
right
now
and
if
I
add
5
hours,
it
doesn't
mean
necessarily
that
it
will
be
6
p.m,
that
that
might
mean
you
know,
seven
or
five
or
so
on,
depending
on
the
time
zone
and
the
daylight
savings
rules,
and
so
on,
and
similarly
now
plus
five
months
actually
depending
on
the
calendar,
because
you
know
the
the
amount
of
days
in
a
calendar
sorry
amount
of
days
in
the
month,
depending
on
the
calendar,
and
even
you
know
like
leap
months
and
stuff
depending
on
becoming
it
so
that
that's
the
motivation
generally,
but
why
this
syntax?
B
Why
have
we?
You
know,
come
down
to
this
particular
syntax
that
we
are
on
right
now.
We
believe
in
a
few
things,
and-
and
these
were
the
things
that
we
use-
the
sort
of
guiding
principles
first,
was
that
the
suffix
should
be
optional,
all
existing
compliant
strings.
You
know
that
that
people
are
using
in
in
the
software
right
now
should
just
work
in
you
know.
The
suffix
should
just
be
additional
information
that
should
not
be
necessary
in
determining
the
in
the
instant
itself.
B
The
time
zone
suffix
was
actually
borrowed
from
java
for
compatibility
reasons.
So
so
you
might
be
wondering
why
this
generalized
format
is
present,
but
then,
at
the
same
time,
there's
this
non-generalized
times
like
you
know,
snowflake
time
zone,
part,
and
that's
because
you
know
java
and
other
tools
already
utilize.
This
format-
and
it's
it's
better
to
you-
know,
allow
that,
for
compatibility
reasons.
B
B
This
I
mean,
of
course,
all
these
are
implementation,
details
that
we
can
argue
about,
but
at
the
time
the
champions
believed
that
that
you
know
keeping
the
actual
data,
the
the
set
of
keys
and
the
set
of
acceptable
values
out
of
the
rfc
would
would
mean
that
you
know
the
the
rfc
can
stay
focused
and
it
could
focus
on
standardizing
the
format
itself.
B
And
then
you
know
there
could
be
other
ways
in
which
we
could
specify
the
keys
and
the
values
that
they
can
hold,
and
and
for
that
part
we
we
board
the
ayana
registry
pattern
from
bc347.
So
just
for
a
little
bit
of
context,
what
happens
in
in
bcp-47
is
that
you
know
there's
different
name
spaces
like
the:
u
name,
space
which
is
registered
by
unicode,
and
then
you
know,
everything
which
is
you
hyphen,
something
is
is
governed
by
unicode,
so
they
can.
B
B
But
that's
just
of
course,
one
of
the
many
ways
we
can
do
this
so
and
yeah.
The
key
hyphen
value
format
in
bcb-47
was
replaced
by
key
equals
value
here
for
for
better
parsing.
B
So
what
we
noticed
was
that
if
we,
if
you
did
key
hyphen
value-
so
in
this
case
u
hyphen
c
a
hyphen
hebrew
that
you
know
based
on
the
rules
for
piano
time
zones,
that
that
wasn't
a
a
good
grammar
that
that
wouldn't
you
know
that
wouldn't
reliably
parse,
because
it
couldn't
tell
between
the
the
generalized
boxes
and
the
time
zone
box.
So
that
was
a
problem
and
therefore
we
added
the
we
replaced
the
hyphen
the
equals.
B
And
now
you
know
the
grammar
is
much
more
simpler
and
deterministic,
and
so
we
have
implemented
this
in
the
temporal
polyfill
that
we
maintain
and
it
is
already
working
progress
in
browsers.
So
you
know
this
is
this
is
somewhat
specified.
The
grammar
is
somewhat
specified
in
the
temporal
spec,
and
you
know
we
of
course,
plan
to
normally
refer
to
an
rfc
once
that's
up,
but
for
now,
and
a
browser
is
already
starting
to
implement
that.
B
So,
what's
next
for
for
this
draft
and
for
us
so
on
the
the
temporal
groups
intends
to
ship
in
browsers
soon,
but
but
the
problem
is
that
we
really
shouldn't
be
shipping.
Anything,
that's
not
yet
standard
track.
So
we
plan
to
adopt
this
document
before
shipping,
so
that
you
know,
there's
there's
some
stability
and
some
standard
to
fall
back
to
it
doesn't
seem
to
be
a
great
idea
to
try
to
standardize
a
timestamp
format
in
in
a
language,
spec
and
yeah.
B
I
request
you
to
all
please
review
the
draft
if
you
haven't
yet
and
send
us
your
thoughts
and
the
implementation
details
that
I
talked
about
just
now
are,
of
course,
not
finalized.
We
can
you
can
talk
about
them
in
more
detail,
but
that's
just
what
we've
come
up
with
so
far
and
yeah.
Let's
adopt
this
as
soon
as
we
can.
A
D
I
just
had
a
query:
you
had
an
example
back
on
that
about
slide
six.
She
seemed
to
show
both
a
time
zone
name
and
also
had
a
zed
on
the
end
indicating
it
was
a
utc
time.
Was
that
a
mistake,
because
that
seems
odd?
No,
it
isn't
actually.
B
So
so
yeah.
Thank
you.
That's
that's
a
great
question.
The
the
thing
is
that
this
is
the
instant
itself,
so
the
instant
includes
the
offset
part
that
could
be
z
or
that
could
be.
You
know,
plus
minus
anything
like
offsets
do
and
then
this
part,
the
the
human
time
zone
is,
is
for
the
additional
context
and
for
it
for
the
daylight,
saving
rules
and
so
on.
So
you
know
the
the
actual
instant
itself
does
not
really
depend
on
on
on
this,
because
you
know
the
result
of
the
offset.
B
So
let's
say
if,
if
this
there
wasn't
an
offset
here
right,
if
there
was
just
a
date
time
as
well
as
a
a
time
zone
and
so
the
time
zone
is
is
not
a
offset,
it
could
refer
to
multiple
offsets
and
which
offset
it
is
would
depend
on
on
the
date
time
there
and
even
then
it's
not
it's
not
confirmed,
because
you
know
there
there
could
be
a
a
particular
date
time
that
that
reoccurs
in
different
offsets
for
the
same
time
zone
right.
B
So
you
know
when,
when
london
is
at
plus
one
I
could
have
say
five
pm
and
then
it
goes
to
plus
zero
again
and
then
now
I
have
5
pm
again
and
so
because
of
this,
the
instant
remains
the
same.
The
the
actual
you
know,
resolution
of
the
instance
still
depends
on
the
offset
and
and
this
additional
sort
of
value
of
the
human
time
zone
comes.
You
know
it
is
more
relevant
once
you
start
doing
things
like
hey,
you
know,
what's
what
happens
when
you
know?
D
Sure
I
I
seem
to
call
in
an
earlier
draft.
There
was
an
option
not
to
have
that.
I
don't.
I
have
to
look
at
what
the
draft
currently
says
see
if
that's
still
the
case
like
it
does
seem
to
me.
It's
useful
also
to
be
able
to
say
it's
this
time
in
the
time
zone
and
that's
it,
although
that
I
agree
there
is
the
issue
of
sometimes
two
possibilities
there.
We
have
a
resolution
algorithm
for
that.
D
The
the
I
guess
my
main
concern,
though,
then
is,
is
there
a
draft
intending
to
provide
any
advice
on
what
to
do
if
the
like,
if
they're,
that
that
instant
doesn't
exist
in
the
time?
Well,
okay,
let's
do
it
yeah,
okay,
don't
mind
all
right!
Sorry!
E
Yeah,
so
I'm
trying
to
get
my
head
around
exactly
what
neil's
trying
to
get
his
head
around.
What
if
I
put
some
time
zone
in
there,
that
was
in
the
top.
The
instant
time
that
had
nothing
to
do
with
the
one
in
the
square
brackets
is
that
okay.
B
So
so
because
this
is
just
additional
information
that
has
nothing
to
do
with
the
you
know:
locating
the
instant
on
the
you
know,
timeline
or
something
it's.
It's
then
up
to
the
implementation
right.
So
it
has.
It
has
two
pieces
of
information,
it
has
an
instant
and
it
has
a
time
zone.
Sorry
and
in
the
time
zone
in
in
no
way
corresponds
to
this
incident,
so
right
right
right.
What
we
do
is
that
we
throw
in
this
case,
so
we
say:
okay,
this.
B
This
is
a
valid
string
like
by
the
protocol,
but
you
know
the.
We
cannot
accept
that
within
the
implementation-
and
I
I
suspect
most
implementations
could
do
something
similar,
but
but
this
this
is
still
compliant
right.
B
You
can,
you
can
have
whichever
time
zone
you
want
in
here
and
and
if
that
doesn't
make
sense,
if
this
information
doesn't
make
sense,
you
know
the
the
the
val
the
the
location
of
the
instant
in
the
timeline
doesn't
really
change,
because
you
know
you
have
all
the
information
you
want
right
here,
but
then
the
implementation
could
could
do
what
it
feels
best.
E
And
so
let
me
ask
about
this
because-
and
this
goes
back
to
some
of
the
thoughts
I
was
having
when
you
presented
this
at
dispatch,
it
seems
to
me
that
you've
got
you.
Do
have
two
separate
pieces
of
semantics
here.
You've
got
what
time
is
it
now
relative
to
universal
time?
This
particular
time
says
you
know
it's.
E
You
know
somewhere
around
10
47
in
the
morning,
oh
in
universal
time,
so
that
that's
what
that
z
is
telling
me,
and
so
I
can
calculate
universal
time
from
this
and
and
even
if
it
had
minus
600,
I
could
calculate
universal
time
from
the
left-hand
side.
The
stuff
on
the
right-hand
side
is
telling
me
what
like
summertime
rules.
I
should
apply
where
things
might
switch,
and
that
does
seem
like
semantically
separate
information.
B
Right
so
so,
as
I
said,
like
yeah,
the
the
implementations
could
could
do.
Something
could
essentially
do
whatever
they
feel
best.
Of
course,
in
these
cases
right
in
case
of
temporal,
we
we
realized
that
you
know
a
a
offset
that
doesn't
really
match
in
any
way.
B
With
this
you
know,
time
zone
would
would
most
likely
be
a
programmer
error,
because
that's
what
we
are
usually
dealing
with,
and
so
so
so
we
decided
that
the
general
case
in
this
scenario
would
be
to
throw
unless
you
know
the
programmer
specifies
what
logic
to
do
when
they
mismatch,
but
but
I
suspect
there
could
be
many
more
interesting
things
to
do.
B
In
this
case
I
mean
one
thing
would
be
to
just
downgrade
this
to
like
downgrade
the
result
of
this
mismatched
string
to
to
a
sort
of
object
that
that
exists,
and
you
can
do
operations
like
comparisons
on
it.
But
then,
as
soon
as
you
do
arithmetic
operations
on
it,
it
doesn't
work
because
you
cannot
do
arithmetic
operations
on
it.
Without
that
context,
right.
E
I
I
guess
what
I
would
say
is
what
you
should
probably
put
on
hold
the
idea
that
this
should
be
implementation,
dependent
or
rejected,
because
it
might
be
the
case-
and
I
think
it's
worth
more
discussion,
that
these
kind
of
things
might
be
useful.
What's
producing
the
instant
time
might
be
a
very
separate
process
or
a
separate
piece
of
code
than
what's
producing.
What
is
my
locale
and
and
what
rules
should
I
apply
to
ongoing
times?
E
And
so
I
I
think
it's
an
interesting
question
as
to
whether
these
really
should
be
treated
as
separate
pieces
of
data
that
are
independent
of
each
other
in
some
way.
Yeah.
A
E
As
mentioned
in
the
chat,
someone
is
typing,
who
is
unmuted
you
might
want
to,
but
that'll
be
me.
I
guess.
A
B
Yeah,
I
think
I'm
starting
to
understand
what
you
mean
here
more
so
so
I've
thought
of
use
cases
like
these
right.
You
could
have
say
a
a
database
that
scores
just
the
timestamp
part
right
and
it
changes
everything
to
universal
time,
so
it
sort
of
does
the
offset
handling,
let's
say
before,
storage
and
so
you're
getting
this
time
stamp
part,
maybe
from
some
other
place
and
and
then
this
is
stored
in
another
venue
and
then
you're
you're,
maybe
compiling
this
on
the
fly.
B
So
so
I
understand
like
that
that
there
are
use
cases
like
this,
and
I
think
I
I
what
I
don't
understand
is
that
what
I'm
suggesting
here
is
can
can
perfectly
work
with
that
right
I
mean
it's
even
if
there's
an.
E
Issue,
absolutely
I
don't
disagree
with
that
part
and-
and
so
I
think
it's
worth
discussion
and
I'll
finish
off
and
it
so
I'll,
let
keith
you
know
hop
on,
but
I'll
finish
off
by
saying.
I
think
a
lot
of
this.
You
know
sort
of
applicability
context
where
you
would
use
these
things
and
why
and
how
they
get
used
is
probably
worth
adding
to
the
document
in
some
way,
because
I
think
people
are
going
to
have
lots
of
different
uses
for
these
sorts
of
things
and
it's
probably
worth
explaining
somewhere
in
the
document.
E
If
you're
using
this
for
simple
what
time
is
it
now
stamps?
You
probably
don't
want
the
right
hand
side,
you
know
all
of
the
additional
suffixes,
whereas,
if
you're
using
it-
and
it's
therefore
going
to
be
calculated
for
things
in
the
future
or
the
past,
you
probably
do
want
to
include
the
time
zone
information
where
this
thing
was
created.
B
Yeah,
no,
that
that
sounds
like
great
advice
things
I
think.
Maybe
we
could
add
a
use
cases
section
or
something
like
that
in
in
the
draft,
and
we
could
talk
them
in
more
detail
about
you
know
what
kinds
of
different
information
would
be
relevant
in
which
cases
and
in
which
cases
you
could
just
say
three
more
of
them.
B
So
so
that
way
it
could
be
both
a
you
know,
sort
of
guideline
for
producers,
but
also
like
consumers,
where
I
could
say:
hey,
I'm
I'm
building
this
sort
of
application,
which
doesn't
really
do
any
calendaring,
doesn't
really
do
any
scheduling.
So
I
I
could
just
focus
on
the
instant
part
and
just
ignore
everything
else,
because
it's
not
necessary
for
my
particular
class
of
applications.
F
All
right,
I'm
keith,
so
I
definitely
appreciated
the
sort
of
example
use
cases
that
you
gave
in
the
presentation.
That
was
something
that
I
didn't
think
was
necessarily
clear
from
the
document,
though,
that
that's
sort
of
what
came
to
mind
having
having
done
some
work
in
the
area,
and
I
think
you
did
clarify
a
lot
of
this
based
on
the
previous
discussion
about
how
kind
of
the
left-hand
side
is
dealing
with.
F
What
is
the
particular
instance
of
time
that's
being
described
on
the
right
hand,
side
with
the
time
zone
is
more
deal
more.
How
to
deal
with.
You
know,
adding
months
figuring
out
how
that
would
translate.
One
thing
that
kind
of
went
against
it.
That
you
said,
though,
is
is,
would
you
be
allowed
to
have
a
time
on
the
left
that
doesn't
have
something?
That's
designated
the
offset,
I'm
just
thinking
that
that
could
be
sort
of
difficult
where
you
know
most
time,
you
don't
need
to.
B
Yeah,
I
thank
you
for
that
question
that
that
is
something
that
has
troubled
us
quite
a
lot
and,
and
it
has
troubled
us
because
on
one
hand
there
are
important
reasons
for
for
sort
of
forcing
people
to
have
things
like
the
the
offset
here,
because
you
know
that
way.
The
the
value
of
the
instant
itself
does
not
really
depend
on
on.
B
You
know
some
of
this
information,
which
you
know
we
as
we
mentioned
in
the
dock,
that
like
we,
we
consider
this
additional
information
additional
context,
and
you
know
so
so
it
feels
that
it
doesn't
seem
to
be
a
great
idea
if
this
optional
context
can
affect.
What's
the
what's
the
resolution
value
of
this
part
right.
B
But
at
the
same
time
I've
talked
to
to
many
people
who
you
know,
work
on
calendaring
applications
or
things
that
deal
with
time
scales,
for
example,
who
would
be
very
happy
to
to
see
something
like
that,
and
what
I
suspect
is
is
that
you
know
it's
a
tricky
problem,
but
I
think
it
might
have
solved
itself
in
a
way
so
right
now
what
we.
What
we
do
is
that
we
no
longer
deal
with
any
of
this
part
right.
B
Any
of
the
part
in
the
left
is
is
just
you
know,
we
we
defer
to
rc3239
and-
and
we
just
specify
the
suffixes,
so
this
this
would
essentially
mean
I.
I
feel
that
that
any
any
standard
that
that
fuels
that
it's
you
know
compliant
with
or
can
replace
rfc
229's
instant
values,
could
could
essentially
attach
and
use
this
extension
for
that
right.
It's
it's
not
what
we
have
in
the
draft
itself.
B
The
draft
itself
uses
339,
but
you
know
some
of
the
implementation
spread
could
could
sort
of
de
facto.
Something
like
that.
So
that's
what
I
feel
I'm
looking
forward
to
working
with
some
of
the
people
who
who
work
more
on.
C
B
Applications
like
calendaring,
which,
which
sort
of
need
you
know
this
offset
part,
for
example,
to
just
go
away
and
and
see
you
know
if
there's
a
better
way
to
to
address
their
use
cases,
because
I
don't-
and
I
don't
have
enough
context
about
these
cases
but
yeah-
I
I
think
it's
there's
certainly
a
lot
of
strong
use
cases
or
for
allowing
some
parts
to
be
skipped.
B
The
the
temporal
the
temporal
implementation
also
does
allow
the
the
offset
to
be
skipped
in
some
cases,
but
then
it
also
you
know
the
the
it's
it
works
out
for
us,
because
it
also
doesn't
need
the
times
the
time
zone.
Information
in
those
it
just
allows
you
to
have
like
a
bare
date
right
and
then
you
can
specify
a
calendar
with
the
date.
So
so
that's
what
we
use
that
for,
but
yeah
I
I
can
understand
real
use
cases
for
skipping
some
of
this
information.
B
F
Okay,
so
another
thing
that
I
just
want
to
bring
up
is
that
time
zone
name
is
typically
referring
to
an
external
system
file,
at
least
in
in
unix
that
might
change.
It
might
be
a
file
that
you
don't
have,
and
so
one
thing
that
I
sort
of
thought
about
about
leaving
out
the
offset
in
the
instance
is,
if
you're
actually
talking
about
something
in
local
time
in
the
future.
B
B
B
You
know
different
services
and
so
on
and
then
like
it
can
change
in
a
million
ways
you
could.
You
could
send
a
time
stamp
to
somebody
on
like
a
different
system,
and
you
know
things
could
just
get
funny.
So
I
completely
understand
that's
precisely
why
we
right
now
require
all
of
the
information
and
yeah
any
any
sort
of
effort
that
makes
parts
of
this
optional
would,
of
course,
need
to
sort
of
justify
what
to
do
in
these
edge
cases,
where
things
get
tricky
to
use
of
pinpoint.
F
D
Okay,
hi
neil
again,
I've
woken
up
a
little
bit
more
now
so,
including
the
offset
does
not
work
for
calendaring
systems
because
time
zones,
daylight
savings
rules,
change,
they're,
political.
They
can
and
do
change
at
any
time.
And
if
you
schedule
something
at
1
pm
6
months
in
the
future
and
the
times
and
rules
change,
you
want
to
be
able
to
semantically
say
no,
no,
I
still
want
it
to
be
at
1
pm.
Not
have
it
shifted
to
now
2
p.m,
because
I
stored
this
as
a
timestamp.
D
That's
kind
of
the
whole
reason
that
you
store
it.
So
all
the
counting
stuff
you
store
as
the
war
clock
time
plus
the
time
zone
name
including
the
time
zone
set
as
well,
seems
just
really
weird.
At
this
point
I
mean
you
could
include
it
as
it
was
at
the
time
and
then
you
have
to
deal
with
what
happens
if
if
it
doesn't
match,
but
the
time
zone
name
is
actually
the
important
bit
not
the
offset
it's
not
actually
a
time
stamp
at
that
point.
Importantly,
it's
a
date.
D
Its
resolution
is
does
depend
on
the
times
of
information
and
my
visual
understanding
of
temporal
that
maybe
it's
changed
since
I
last
looked
at
it
was
that
you
have
objects
that
represent
represent
this,
like
a
walk-up
time
plus
time
zone
and
even
a
walk-up
time
on
its
own,
and
that
doesn't
seem
to
be
stuff
that
you
can
represent
in
a
serialized
way
here,
which
is
surprising
because
that's
what
you
originally
brought,
I
thought
that's
what
you
needed.
B
So
so,
in
the
context
of
temporal
this,
this
format
is
used
in
in
what
we
call
a
zone
date
time
which
is
is
which
is
essentially
just
an
instant
and
and
like
it's
it's
it's
tuple,
which
has
an
instant
as
well
as
a
time
zone
object.
So
so
this
is
what
it
serializes
to.
I
I
completely
understand.
D
B
Yeah,
I
I'm
not
sure
if
it
takes
if
it
goes
to,
but
is
there
any
semantic
difference
between
z
and
plus
zero
zero.
D
Not
not
not
really,
except
I'm
it's
more
interesting
of.
Is
it
meant
to
be
encoding.
The
current
offset
in
the
time
symbols
it
understands
at
this
time,
but
even
then
it
you're
you're
losing
what
the
wall
clock
time
was
well.
Okay,
yeah,
it's
okay,.
D
With
both
of
those
not
if
you've
changed
for
the
offset
like,
if
you
should
be
able
to
get
the
walk-up
time
by
just
truncating
at
the
offset,
otherwise
we're
gonna
not
be
able
to
resolve
the
correct
information
if
the
time
zone
definition
changes
which
it
can
and
does
right
so
so
yeah
it
was
in.
B
B
Yeah,
so
so
that's
that's.
I
guess
one
of
the
trade-offs
that
I
I
was
hinting
to
when
discussing
keith's
question
right,
so
it's
it's
really
useful,
for
I
completely
understand
for
calendar
calendaring
applications
to
to
be
able
to
skip
the
offset
part,
but
then
that
means
that
whatever
the
your
your
resolution
of
this
timestamp
value
is
essentially
depends
on
this
additional
context.
So
then
it's
no
longer
optional.
B
It's
it's
necessary
and
yes,
I
mean
that's
requirement
for
the
calendar
yeah,
but
the
the
thing
is
that
then
it
starts
getting
more
interesting
when
you,
when
you
consider
consider
some
of
the.
C
B
You
know
tags
that
we
are
talking
about
right.
So
if
I
say
things
like
you
know,.
B
That
could
essentially,
you
know,
be
made
to
work
as
well
and
and
there's
merits
and
demands
to
that,
because
you
need
to
first
deduce
this
information
like
at
the
end.
You
need
to
figure
out
the
suffixes
before
resolving
this
or
before
even
parsing
this,
because
the
the
resolution,
or
in
case
of
calendars,
the
the
parsing
itself
would
would
depend
on
on
this
value,
and
I
think
this
is
also
relevant
for
the
the
class
of
use
cases
that
require
time
scales.
B
I'm
I'm
not
very,
you
know
proficient
with
with
those
use
cases,
but
I've
been
talking
to
some
of
the
people
in
npp
who
are
very
interested
in
the
possibilities
of
that.
So
what
I
propose
is
that
we
we
should.
We
should
talk
about
this
exact
class
of
use
cases
within
the
within
the
working
group.
B
So
you
know
we
could
we
could
talk
about
the
the
the
different
ways
where
we
would
resolve
things
and
in
case
that
we
allow
the
the
offset
to
not
be
included
and
if,
if
we
can
reach
a
settlement
in
in
a
way
that
it
satisfies
everyone-
and
you
know
sort
of
helps
the
format
I
I'd
be
more
than
happy
to
to
sort
of
allow
that
use
case
I
mean
that's.
That's
the
whole
point
of
the
initiative.
B
A
It's
like,
we
definitely
have
a
work
item
to
do
here
before
we
publish
the
document.
Obviously,
but
there's
yeah.
There
seems
to
be
two
things
here,
one
of
which
is
the
requirement
to
have
the
left
hand
side
understandable
in
isolation
without
any
of
the
right
hand,
side
parts
which
is
encoded
in
our
charter,
that
it
should
be
possible
for
a
client
that
doesn't
understand
the
right
hand,
parts
to
still
parse
the
left
hand,
part
and
also
the
idea
of
replacing
the
floating
date
plus
time
zone,
that
is
in
calendaring
systems
already
and
there's.
A
Certainly,
there
are
plenty
of
use
cases
that
require
that
there
are
also
plenty
of
use
cases
that
want
a
point
in
time,
particularly
for
the
past.
When
you
you
know
what
point
in
time
something
happened
for
the
future,
it's
harder
to
predict
exactly
what
point
in
time.
Something
will
happen
and
you
might
want
to
address
it
in
different
ways
that
are
not
exact
utc
time,
but
anyway,
hank
was
next.
So
I
think
my
question
was
covered
by
by
what
neil
had
so
I'm
gonna
pop
out
of
the
list
and
go
for
it.
G
Hi
thanks
yeah,
this
is
hank,
so
I'm
I'm
I'm
not
trying
to
elaborate
on
the
actual
complete
contributions.
I
I
don't
really
understand,
but
the
problem
has
been
solved,
but
that
might
just
be
me,
so
this
is
just
a
hank
problem.
I
assume,
but
speaking
as
one
of
the
people
who
is
interested
in
doing
the
sibo
time
tag,
we
realize
to
some
extent
yeah
that
time
zones
are
fluid.
G
G
First
of
all-
and
so
you
are
adding
complexity
by
by
now
having
dependency
of
not
having
just
knowing
an
arbitrary
offset,
but
you
have
to
resolve
what
europe
london
means.
I
mean
london
might
have
changed
its
time
zone
after
brexit.
I
don't
know
you
know,
or
europe
might
introduce
the
summer
daylight,
saving
time
thing
or
basically
get
rid
of
it,
and
so
so
this
might
all
change.
G
So
this
is
so
that
whatever
uses
this
has
to
resolve
that,
and
that
is
a
dependency
to
some
other
so
like
like
tz,
announce
and
then,
and
then
you
actually
never
really
know
for
the
future,
how
that
works.
So
I
don't
know
in
which
time
zone
london
is
in
20
years,
although
I
cannot
express
that
exactly
in
utc,
I
think
is,
was
applied
because
that
it
is
impossible
to
pre
define
the
date
in
the
far
future
with
utc.
G
But
but
then
we
realized
that
probably
the
most
safe
way
to
do
it
is
to
use-
and
this
is
not
a
joke-
geodetic
systems
like
wgs
to
say
where
that
is
in
the
future,
and
then
at
that
point,
when
it
comes
out
find
out
which
time
zone
there
is
now.
Is
this
still
plus
six,
or
is
this
now
plus
five
or
five
point?
Five?
I
don't
know
so.
That
is
something
that
is
also
again
adding
complexity
here,
so
so
again,
not
not
really
realizing
what
the
problem
is.
That
is
solved.
G
I
just
wanted
to
highlight.
You
are
adding
complexity,
and
quite
a
lot
of
it
here
right
so
just
be
aware
of
that.
B
Yeah,
absolutely
so
I
I
think
this
is
best
encapsulated
and
rest
by
the
sort
of
point
race
by
pete
and
the
the
sort
of
resolution
that
we
reach
for
it,
which
is
that
I
I
agree
that
not
all
the
that
there
can
be
in
at
some
point
in
the
future.
A
very
large
set
of
of
accepted,
accepted
values
that
can
be
included
at
the
end
of
this
frame.
Right
and
you
know,
different
sets
of
these
values
can
be
useful
for
different
applications.
G
B
Right,
but
so
that's
that's
only
relevant
if
your
clock
is,
is
you
know,
utilizes
this
information
in
which
case
should
already
be,
and
so,
if,
let's
say
there
is
a
time
stamp,
sorry
a
time
scale
mentioned
after
this-
and
I
am
just
you
know,
a
regular
calendar
developer.
I
don't
care
about
time
scales
because
I'm
not
building
anything
that
would
the
atomic
time
I
I
wouldn't
care
about
it,
and
I
could
just
you
know,
ignore
that
value
safely.
B
If
I
am
building
tools
that
only
care
about
things
in
gregorian
calendar,
I
you
know,
wouldn't
care
about
the
calendars,
so
I
don't
have
a
dependency
on
unicode
anymore,
yeah.
G
Now
I
would
be
very
careful
here
because
you're
mixing
calendars,
which
is
a
thing:
how
to
distinguish
days
with
the
time
scales,
which
is
how
to
how
segments
are
counted.
That
is
different
things.
I
think
because,
for
example,
I
don't
know
utc,
tai
or
ut1
or
ut2.
These
are
different
time
scales.
G
They
typically
have
different
epochs
or
could
have
the
same
epoch
and
and
calendars
are,
I
think
yet
another
thing
and-
and
I
think
it's
very
important
to
not
mix
up
the
idea
of
of
counting
days
and
calendars
and
and
representing
time
as
I
think
we
are
trying
to
do
here.
B
I,
I
think,
that's
I,
I
think
that's
sort
of
exactly
the
point
I
was
trying
to
make
is
that
you
know
the
set
of
values
that
can
and
should
be
represented
eventually
at
the
end
of
this
would
vary
significantly
right.
Some
of
them
would
be
useful
for
certain
kinds
of
applications
and
then
others
for
other
kinds
of
obligations,
and
I
I
think
the
the
complexity
that
is
added
for
a
implementation
is
is
only
relevant
to
to
which
information
you
actually
want
to
consume.
B
So
if
I,
if
I'm
building
a
a
implementation,
that
just
only
cares
about
the
instant,
maybe
I
am
just
rocking
time
stamps
for
a
logging
tool,
and
I
really
don't
care
about
anything
that
that
is
at
the
end
of
this
I
I
could
ignore
all
of
it
and,
and
so
so,
the.
C
B
Is
that
you
could
selectively
pick
the
values
that
are
relevant
to
you
and
and
that
you're
you
know
you,
you
would
be
consuming
and
everything
else
is
just
additional
information.
That's
not
useful
to
you!
So,
okay.
G
Oh
okay,
so
but
they'll
never
just
part
with
a
a
very,
very,
very
subjective,
individual
comment
when
I
write
emails
and
and
then
if
I
orchestrate
a
event
between
participants
in
different
time
zones,
I
always
say
like
it's
p
d,
t
e
d,
t
b,
t
b
s,
t
and
c
t,
for
example,
at
the
moment
and
then
and
then
write
them
all
down
just
for
people
to
make
it
easier
and
and
then
I
give
a
plus
offset
so
people
don't
have
to
understand
what
does
cst
mean?
I
mean
not.
G
Everybody
knows
so
it's
a
plus
two
at
the
moment.
So
that's
that's
interesting
to
people
and
then
that
is
what
they
consume,
the
the
actual
digit
and
they
don't
care
if
I'm
berlin,
but
they
care
that
I'm
two
hours
plus
to
the
utc
z
here
and
so
so
so
that's
my
personal
assumption.
But
again,
maybe
I'm
not
really
getting
the
problem
statement
that
the
thing
they're
trying
to
solve
and
and
so
but
again
my
comment
was
about
adding
complexity.
Just
be
careful.
B
B
Oh
okay,
sorry,
the
the
interface
doesn't
show
me
speaking
anyway,
so
so
you're
only
sending
those
emails
out
for
say
the
next
meeting,
where
you
you,
I
mean,
of
course
you
deterministically
know
the
offset.
But
and
and
you
know
it's
it's
just
right
away.
But
if
you
were
saying
you
know,
if
you
were
sending
out
emails
for
you
know
five
months
into
the
future,
you
would
I
mean
still
deterministically
know
the
offset,
but
things
have
changed
and
and
so
on,
and
you
know
a
couple
years
into
the
future.
B
You
can't
even
tell
because
europe
might
review,
remove
daylight
savings
right,
yeah.
G
B
Right
which,
which
is
why
you
can
specify
the
time,
scale,
that
we
are
talking
about
right
it's
in
in
then
you
can
say
hey
this
is
this
is
not
so,
for
example,
temporal
is
as
an
example.
I
think
I've
mentioned
it
quite
a
bit
at
this
point,
but
yeah
temple
doesn't
account
for
lead
seconds.
It's
just
you
know.
C
G
So
yeah,
but
this
is
utc.
You
know
so
this
this
this
you're
basing
it
on
the
333
something-
and
I
guess
that's
utc
you're
stuck
with
that
right
right.
So
that
doesn't
mean
anything
about
any
other
time
scale.
B
B
C
One
comment
that
that
there's
been
a
thread
in
the
chat
which
people
should
do,
which
people
should
pay
attention,
but,
more
generally
or
and
join
someone
in
the
comments
or
the
loop
which
has
been
made.
The
syntax
here
is
easy.
The
use
cases
get
complicated.
C
C
What
what
applicability
of
this
means,
where
it's
applicable,
where
it
may
not
be
applicable
and
to
spell
out
whatever
the
kinds
of
issues
are
which
have
just
been
discussed
in
other
ones,
that
that
apply
to
each
other's
use,
cases
or
or
narrow
it
down
completely
and
say
this
is
good
for
for
these
three
things
and
and
whether
it
works
ready
for
anything
else
is
a
is
a
matter
of
future
investigation.
C
But
we
are
we're
we're
in
danger
of
of
getting
into
very
extreme
hand
waving
here
and
that's
and
that's
not
good
for
anybody.
Thanks.
B
That's
that's
perfectly
reasonable
thanks.
I
I
think
either
way
we
progress.
We
can.
We
can
strongly
make
a
case
for
the
different
information
that
that
you
know
sets
of
information
we
care
about
right
now.
So
I
I
think
if
we,
you
know
after
the
after
discussions
about
this,
if
we
end
up
with
a
solution
that
that
restricts
the
set
of
information
to
say
three
things,
that's
that's
workable
in
yeah,
just
just
an
implementation
detail.
I
wouldn't
be
too
sad
about
it.
C
B
Right
yeah,
I
I
understand
the
the
downside,
or
maybe
potential
downside
of
specifying
only
all
the
different
sets
of
values
within
the
document
is
is,
of
course
I
mean
not
a
downside,
if
you,
if
you
like
that
kind
of
quickness,
would
be
that
any
additional
information
that
can
be
supported
by
the
format
would
need
an
update
to
the
rfc
itself,
which
is
a
long
process.
So
so
yeah
there's
there's
a
trade-off
there
and
I
I
I
don't
feel
strongly
about
the
the
way
it's
done
currently.
B
So
what
I
meant
was
that
you
know
that
that
if,
if
there's
a
strong
case
for
either
direction,
I'd
be
I'd
be
happy
with.
C
B
Right
yeah,
another
point
likely
in
the
favor
of
that
argument
was
that
bcp-47,
although
it's
it's
a
nice
kind
of
format,
to
do
these
kinds
of
things,
it
is
a
very
different
use
case
right,
it's
locales
and,
and
that
that
I
I
don't
feel
that
it's
as
sensitive
information.
B
Hopefully
I
mean
I
I'm
hoping
that
there's
no
possibility
of
including
it
you
know
long
longitude
latitude
within
a
low,
calcium
right,
but
that
that
things
could
be
different
here.
So
so
I
agree.
If
you
know,
if
we
decide
to
go
more
strict
in
this
particular.
B
A
One
we
had
in
the
queue
for
now.
Certainly
there
are
a
couple
of
issues
there
that
we
know
we're
going
to
need
to
resolve
in
future
versions
of
this
draft
before
it's
ready
for
publication.
A
Was
there
anything
else,
because
we've
spent
all
that
time
focusing
on
on
this
this
one
specific
issue,
anything
else
that
we've
wanted
to
talk
about
here.
B
If,
if
there's
nobody,
maybe
I
could
ask
a
question:
yeah
go,
so
it's
it's
more
about
the
eitf
process,
but
I
think
it's
relevant
in
this
case
so
from
what
I'm
familiar
with
in
in
the
tc39
process.
What
we
do
is
that
when
we're,
you
know
progressing
the
different
proposals
right.
We
while
progressing
up
the
stages.
We
we
have
a
point
where
we
say
okay,
this
is
the.
The
committee
has
achieved
consensus,
that
this
is
a
problem
that
we
feel
is
worth
solving,
and
so
this
can
progress.
We
haven't
er.
B
We
don't
have
consensus
on
the
exact
details
around
how
how
we
want
this
to
be
solved
exactly,
but
but
we
do
agree
that
this
is
a
problem
where
it's
being
solved
right.
So
I
I,
when
I
think
about
the
ietf
process.
I
think
that
that's
you
know
the
it's
analogous
to
adopting.
I
feel
right
so
so
adopting
the
document
essentially
means
that
that
we,
you
know
that
we
agree
that
this
is
a
problem
that
needs
to
be
addressed
and
and
now
the
working
group
can
can
work
together
and
address
that
problem.
B
Of
course,
in
in
whatever
way,
everybody
agrees
is
a
good
idea.
So
so
my
question,
then,
would
be
that
you
know
these
are
all
great
concerns,
and
I
agree
that
these
are
all
important
things
that
we
need
to
talk
in
detail
about.
What
are
these
things
that
we
are
these
things
that
can
be
done
within
the
working
group
after
adoption
or
or
do
any
of
these?
Actually,
you
know
block
adoption
and
then
need
to
be
resolved
before
we
do
that.
A
Yeah
adopting
is
deciding
that
this
document's
the
right
starting
point
for
that,
as
pete
says
in
the
chat
again,
which
is
basically
what
I
was
going
to
say
that
yes
adopting
the
document
means
saying
that
that
we're
happy
to
use
it
as
a
starting
point.
It's
happened.
It's
where
we're
happy
to
go
from,
but
it
doesn't
mean
we're
happy
it's
in
the
final
shape.
A
So
I
I
very
much
doubt
that
we're
going
to
get
any
strong
pushback
to
adopting
the
document
as
a
starting
point.
One
thing
that
I
didn't
specifically
put
in
the
slides
that
we
will
need
to
consider
during
this
session
is
co-authors.
Potentially,
if
there's
someone
else
who
wants
to
work
on
the
document
with
you,
so
I
will
certainly
be
doing
a
call
for
volunteers
to
co-author
the
document.
A
I
guess
we're
basically
there
if
there
aren't
any
more
questions
about
the
document
as
it
is
now.
The
other
question
will
be
workflow
whether
you
prefer
to
use
github
issues
or
emailing
list
threads.
To
keep
track
of.
What's
being
worked
on,
discussion
will
definitely
happen
on
the
mailing
list,
either
way.
B
A
All
right
does
anyone
want
to
step
forward
to
volunteer
to
help
with
the.
A
A
Yeah,
yes
twist
twisting
arms
is,
is
going
to
be
the
definitely
the
way
to
go
here.
A
All
right:
well,
the
other
question
here
was
milestones
and
any
other
business.
So
do
we
have
any
other
business
first
and
let's
have
a
look
at
the
milestones
as
well.
A
All
right,
so
our
existing
milestone
is
for
december
this
year
to
submit
the
document.
Obviously
I
will
be
adding
a
milestone
for
formal
adoption
of
the
draft
in
august
2021.
At
this
rate,
the
question
of,
can
we
move
faster?
I
think
has
basically
been
solved
with.
It
is
unlikely
that
will
be
done
before
december
2021,
given
that
we
have
a
couple
of
significant
open
questions
and
we
don't
have
a
volunteer
second
editor
yet,
but
certainly
we'll
move
faster
if
people
participate
quickly.
A
A
All
right,
thank
you.
Everybody.
It's
been
a
good
first
session.
I
think,
overall,
apart
from
the
the
lack
of
volunteers,
I'll
get
my
arm
twisting
working.
A
And
I'll
see
you
next
time
see
you
on
the
mailing
list.