►
From YouTube: Spec 3.0 meeting (February 1, 2023)
Description
B
C
B
C
B
B
D
I
mean
you
got,
you
got
more
than
three
I
said.
The
minimum
is
three
right:
three
approvals
in
the
reaper
right.
Well,
in
this
case,
it's
it's
not
minimum
three
I
think
it's
not
set
up,
but
but
yeah
we
honor
it
like
it's
three
so
or
we
try
to
honor.
So
so.
You've
got
more
than
three
approvals
and
you
left
some
decent
amount
of
time
like
two
weeks.
I
think
it's
good
enough
amount
of
time
to
for
someone
to
just
jump
into
it.
You
pinged
him
how
many
times
I.
D
D
D
So
yeah
so
and
then
how
much
time
do
you
let
it
pass
until
you
hit
the
merge
I
think
that's
gonna
depend
a
lot
in
the
type
of
pull
requests
if
it's
a
big
one
important
one
or
if
it's
just
a
stupid
thing.
If
it's
a
stupid
thing,
and
this
guy
had
emerged
one
week
one
week
after
right,
if
you've
got
enough
approvals,
just
go
ahead
and
merge
it,
and
and
if
it's
a
big
one,
that
it's
going
to
master-
and
you
know
it's
important
one
and
so
on.
D
B
D
But
but
that's
the
thing
right
like
we're
humans
in
the
end
and
every
everything
is
relative
right
so
and
there's
no
easy
way
to
actually
put
it
there
clearly
for
each
case.
So
you
really
have
to
leverage
your
soft
skills
here
and
being
trying
to
be
polite
and
respectful
with
the
community
so
and
you've
been
respectful,
come
on
two
weeks
after
last
time
you
pinned
people
or
in
this
case
look
at
Spring
people
I.
D
Think
that's
more
than
enough,
and
on
top
of
that
you
got
four
co-downers
out
of
five
or
better,
because
I
think
we're
five
four
of
our
five
who
approved
it,
and
on
top
of
that,
it's
going
to
release
a
branch,
not
too
massive.
So
there
yeah,
not
everything,
is
or
or
I
I.
Don't
think
not
everything
should
be
coded
into
you
know
into
the
rules
and
everything
like
it's.
B
Hard
for
it's
hard
for
a
contributor-
that's
that
isn't
a
code
owner
to
know
when
when
something
is
that
fluent
right
so
but
yeah
it
might
just
be,
it
might
just
be
that
one
of
you
code
owners
or
a
code
owner
explicitly
State.
Well,
we
do
this
and
then
we
merge
it.
So
it's
up
to
the
code
owners
to
set
the
tone
of
when
something
is
okay
to
merge.
D
It's
part
of
the
game.
Man
like
it
might
be
hard
for
people
to
figure
it
out,
but
yeah
you're
part
of
a
community
to
chat
with
the
community
and
say
yes,
I,
don't
know
if
I
should
imagine
this
or
not,
and
then
someone
yeah
yeah,
you
know
like
it's
part
of
it
like
we're
humans,
we
can
communicate.
So
if
you,
if
you're,
not
right
or
not,
I,
know
I
know,
but
I
should
be
able
to
communicate.
A
C
To
merge
options
so
anyone
can
trigger
release
the
emerge,
but
it
will
not
work
if
there
are
some
blockers
so
like
in
theory,
like
imagine,
you're
a
contributor
that
you
you've
done
that
in
meetings
you're,
not
in
slack,
you
don't
know
us.
So
you
you,
like
you
shouldn't
wait
for
us.
You
should
just
trigger
RTM.
C
C
My
opinion
yes
and
then
it's
our
problem,
the
the
code
owners
like
how
to
prevent
that
you
do
it
before
before.
We
actually
want
you
to
do
it.
So
in
all
the
other
repos,
it's
not
a
problem,
because
this
RTM
is
really
depending
on
the
settings
in
the
GitHub.
The
only
problem
is
this
and
the
spec,
where
we
know
we
want
to
have
three
reviewers,
but
in
the
settings.
B
C
So
so
basically
it
should
be
like
you
should
just
merge
it.
Then
we
figure
out
how
them
how
to
prevent
it
in
the
future.
And
it's
then
it's
on
the
code
owners
I
think
the
like.
It
should
be
the
me
from
Vladimir
and
Dale
and
and
Sergio.
We
should
meet
and
agree.
Okay,
then
we
should
injection,
schema
and
spec.
We
should
always
use,
do
not
merge
label
and
whenever
we
don't
want
someone
to
use
RTM,
that's
why
do
not
merge
what's
also
invented
sure.
B
B
Then
we
would
have
to
explicitly
state
that
one
binding
is
for
one
major
version
and
another
is
for
version
two,
for
example.
So,
up
until
now,
we
don't
have
any
consensus
on
what
to
do
about
bindings.
It's
just
there
and
it
hasn't
been
part
of
the
the
validation
rules
either.
So
it's
been
kind
of
like
just
there.
B
D
But
we
have
a
change
of
perspective,
for
instance,
the
public
subscribes
and
received.
So
this
might
be.
A
problem
can
be
a
problem.
I
don't
know,
I
have
I
would
have
to
check,
especially
on
the
HTTP.
One.
Probably
I
haven't
checked,
but
might
be
a
a
problem
to
look
at,
but
in
my
opinion
like
what
I
will
do
is
since
we
don't
maintain
multiple
versions
at
the
same
time,
so
we
will
major
versions
at
the
same
time.
So
we're
not
going
to
maintain
two
anymore.
D
We're
just
gonna,
leave
it
there,
but
we're
not
gonna
keep
developing
version.
Two
I
think
it's
as
easy
as
marking
a
line
on
the
on
the
binding
like
up
until
here
up
until
0.2
version
of
The
Binding,
it's
for
version,
two
of
the
spec
and
from
there
on
is
for
version
three
of
the
spec
right.
So
whatever
we
add
on
The
Binding
might
or
might
not
make
sense
on
version
two,
but
I
want
this
feature
on
version
two
I'm.
D
Sorry,
you
had
to
migrate
to
version
three,
that's
what
I
will
do,
because
we
don't
maintain
multiple
versions
of
the
major
versions.
At
the
same
time,
right
so
so
then
I
will
do
select
up
until
here
is
written
to
there
on
its
version.
3.
up
until
here
is
version
three
from
there
on
this
version.
Four,
you
know
like
I'll
continue
like
this,
and
we
can
make
it
clear
on
each
of
the
bindings,
for
instance,
for
in
each
of
the
binders
we
can
just
select.
D
This
is
the
last
version
for
version
two
and
for
version
three.
This
isn't
there's
another
one,
but
that
also
triggers
or
raises
the
question
that
we
don't
maintain
multiple
bindings
versions.
Right,
we
I
mean
we
I
think
we
do
on
the
on
decent
schema
definitions,
I
think,
or
we
were
planning
to
do
it.
I
recall
that
we.
B
D
Right
yeah
but
I
mean
it's
having
a
list
of
all
the
versions
of
a
specific
bindings
you
know
like
and
to
see
how
it
has
been
evolving,
for
instance,
or
I
want
to
go
back.
One
version
on
The,
Binding
I
think
this
is
human
definition,
since
we're
having
something
like
that,
if
I
recall
correctly,
but
yeah
I'll
have
to
check
for.
C
D
D
D
D
Okay,
I'm
gonna
remove
my
face,
which
is
even
better
so
so
yeah
no
problem
with
video
anymore
I
hope
it.
It
helps
with
the
connection
so
yeah
on
on
me.
We
needed
to
have
the
version
of
The
Binding
on
the
distance
schema
for
that,
because
they
were
breaking
changes
from
one
version
to
another
and
yeah,
but
that's
it,
but
we
don't
have
we
don't
get
the
history
of
or
I
think
no,
we
we
needed
it
yeah
yeah!
No,
we
needed
it.
We
needed
it.
D
B
And
this
is
something
we
have
to,
at
least
in
the
current
setup.
It's
something
we
have
to
do
in
the
in
the
readme's,
because
this
spec
files
them
set
like
the
validation
rules
for
the
bindings,
has
no
information
about,
or
has
no
constraint
that
these
only
works
for
an
async,
API,
2.0
or
3.0.
It
doesn't
have
that
constraint
in
itself
as
like.
It's
only
it's
only
validating
the
bindings
themselves
and
it's
not
until
it's
actually
used
now.
I
can't
remember
what
it
is
somewhere
here.
B
D
No
I
mean
what
I
will
do
is
I
will
just
agreement
that
we
can
have.
This
is
getting
outside
the
meeting,
okay,
but
but
other
than
that.
The
only
thing
that
I
will
do
is
just
living
this
node
in
each
of
the
bindings
that
I'm
not
sure
if
I
will
do
it
in
each
of
the
bindings,
but
I
will
review
the
bindings
and
make
sure
they
make
sense
on
version
3..
D
If
they
make
sense,
I
will
not
have
anything
now,
because
bindings
are
an
experimental
stage.
Yet
so
I
will
not
add
anything
yet
and
and
for
and
if
we
get
something
like
I,
don't
know
the
HTTP
binding
it's
a
problem,
then
we
leave
a
message
in
the
on
the
HTTP
by
name
another
rest
and
we'll
leave
a
message
saying
what
I
just
said.
Like
version
two
is
happened
to
here,
question
three
is
from
there.
That's
it
and.
D
B
D
B
B
C
C
A
C
Yeah
yeah
yeah
yeah.
We
need
an
issue,
but
maybe
in
the
same
like
in
during
the
because
in
the
in
this
issue
for
the
review,
you'll
ping,
all
the
code
owners,
so
they
can
already
share
an
opinion
what
they
think
because
I
on
my
own,
like
I'm,
struggling
I,
imagine
solution
without
actually
knowing
that
it's
needed
the
solution
itself
like.
C
Maybe
there
will
be
no
changes
and
that's,
but
we,
but
we
still,
of
course,
need
a
note
that
that
the
current
bonding
conversion
is
compatible
with
two
and
three
but
I'm,
not
convinced
because
I
I
just
look
now
on
the
Kafka
and
it's
zero
four
right
and
it's
at
the
moment
we
have
an
approach
with
Bindings
that
it
works
with
any
minor
release
right.
So
any
one
to
two
to
three
to
four
to
five.
We.
C
A
C
D
B
D
B
D
My
point
you
created
today,
but
we
don't
have
to
address
it
today,
so
you
greet
it
today,
so
we
don't
forget
about
it.
So
we
take
it
into
account
right
and
but
we
can
start
addressing
it
after
we
freeze
the
aircon
battery
and
and
but
in
any
case
there
are
things
that
we
know
that
they're
gonna
make
it
to
version
three
right.
So
most
of
it
we
know
already
it's
a
it's
stable,
it's
I
mean
stable,
it's
it's,
it
makes
sense
or
it
looks
like
it
makes
sense.
D
So
so
we
know
that
we're
gonna
have
a
change
in
the
perspective.
We
know
that
we're
gonna
have
request
reply.
Somehow
we
don't
know
yet
exactly
the
details,
but
you
can
start
thinking.
Oh
in
the
case
that
we
have
request
reply,
is
it
going
to
have
conflict
somehow
cool
so
then
I
might
want
to
as
a
code
owner
then
I
might
want
to
put
a
note
or
reminded
for
me
here
that
after
the
freeze
after
request,
reply
is
merged
and
everything
is
frozen
already,
I'll
review
it.
D
B
C
A
B
We
have
all
the
all
the
all
the
versions
that
are
compatible
with
that
major
version
of
async
API,
and
then
one
of
them
is
of
course
marked
as
the
as
the
latest
one.
That's
the
newest
one.
So
that's
the
default
value
right,
but
all
the
others
are
explicitly
stated
that
they
are
only
matched
against
whenever
The
Binding
version
property
is
specifically
set
for
themselves.
C
C
B
D
C
A
D
A
E
Yeah
I
think
that
may
be
a
mistaken
comment
because
it
looks
like
there's
another
proposal
that
deals
with
you
know
we're
very
interested
in
multi-format,
multi,
schema
format,
support
and
so
that
one
doesn't
look
like
it's
look
like
it
moves
forward,
but
it
looks
like
another
proposal.
That's
very
similar
for
multi
format.
Support
did
move,
move
forward
just
reading
through
it.
E
B
So
the
status
with
that
is,
it
will
not
be
included
as
part
of
version
3,
but
it
is
just
a
feature:
change,
okay,
so
going
forward.
It's
just
a
change
of
at
least
that's
the
idea,
because
we
don't
have
the
underlying
standard
for
it
regarding
references
so
yeah
and
we
don't
have
the
tools
for
it,
which
is
another
problem.
B
B
E
E
A
E
But
it's
possible
that
this
would
be
included
in
B3
right
because
it's
aren't,
it
would
meet
the
the
code,
freeze,
requirements
and
everything
and
it
would
address
you
know.
Potentially,
you
could
use
this
to
put
an
XML
schema
in
there,
because
most
of
the
examples
are
Avro.
But
it
looks
like
you
can
reference
out
to
a
different.
E
E
B
E
Totally
I've
been
down
the
same
road,
so
I
yeah
I,
agree
that
there
isn't
something-
and
it
certainly
seems
like
open
API
struggles
with
this
as
well
I
mean
I.
It
seems
like
we
go
round
and
round
and
round,
and
the
answer
maybe
is
just
have
this-
be
our
own
named
field
rather
than
you
know,
dollar
sign,
ref,
yeah,.
B
B
E
Yeah
yeah
I
totally
get
it
it's
tough
because
it's
a
pretty
pretty
crucial
functionality.
And
but
it's
helpful
to
me
for
me
to
understand
what's
in
what's
out
in
in
terms
of
of
that,
and
you
guys
do
think
and
I
think
that's
right-
that
it's
not
like
necessarily
a
breaking
change,
because
at
this
point.
C
I
actually
I
have
totally
different
opinion.
I
think
we're
mixing
two
different
topics
here:
okay,
so
so
so
there
are
two
things
brought
above
XML
and
stuff,
and
that's
about
referencing
and
and
the
custom
schema
it's
different
custom
schemites
that
you
just
want
to
say
what
schema
like.
You
can
say
that
you
have
XML
it's
just
not
going
to
work,
but
I
mean
you
can
Define
any
any
schema
format
you
want,
and
now
it's
on
the
message
level
and
but
you
just
can't
have
a
reference
to
some
nested
part
of
the
XML.
C
For
example,
data
point
or
whatever
is
the
XML
naming
and
that's
one
topic
and
that's
I,
don't
think
we
enabling
XML
would
be
a
breaking
change.
I,
don't
think
it
would
be
because
it's
as
we
also
mentioned
here,
that
we
can
just
come
up
with
alternative
dollar
reference
field
like
dollar,
whatever
or
whatever
name
of
the
field
that
would
be
custom
just
for
XML
and
that
I
don't
think
it
will
be
a
breaking
change.
C
A
C
Yeah
and
and
this
one
actually,
this
proposal
from
Machi
so
there
are,
there
are
many
different
proposals
involved
in
one
proposal,
but
that's
what
you're
showing
it's
actually
the
the
problem
is,
and
that
was
his
proposal.
So
the
current
problem
is
that,
if
you
don't
like
can
I
share
my
screen,
maybe
yeah.
A
A
C
C
Basically,
the
idea
of
and
that's
why
this
pull
request
from
Machi,
it's
about
extending
objects,
think
schema
objects
because
schema
object
is
in
components
right,
and
the
thing
about
schema
object
is
that
it's
purely
just
a
schema
right.
So
there's,
let
me
so
the
in
the
in
schema.
You
can
just
put
the
name
of
the
schema
and
the
schema
and
his
proposal
was
that,
like
to
overcome
this
issue
that
you
cannot
use
Avro
in
the
in
the
components
was
to
have
a
kind
of
custom
schema.
C
So
so
inside
payload
you
don't
Define
the
schema
directly,
but
you
have
an
object
where
you
can
specify
the
format
and
the
schema,
so
the
format
is
no
longer
defined
on
the
message
level
but
inside
the
payload.
So
that's
at
least
to
my
understanding.
This
is
the
pull
request
about.
This
is
the
solution
and
it
was
like
mainly
driven
by
one
of
the
like
one
of
the
issues
from
the
community
where
actually
from
Michael
from
Solas-
and
it
was
mainly
like
it
was
mainly
related
to
this.
C
C
But
when
I
was
writing,
this
message
I
actually
thought
that
maybe
it's
just
a
bug
in
the
parser,
not
really
technical
problem,
but
that's
different
different
thing,
and
this
is
if
this
is
not
a
problem,
if
that's
not
just
a
bug
with
the
parser,
but
actually
something
more
complicated
like
like,
for
example,
what
was
proposed
by
mache,
then
this
is
a
brain.
This
will
introduce
a
breaking
change
because
it's
it's
a
change
in
the
object,
but
of
course
we
can
always
have
a
tuple
right,
so
we
can
have.
C
We
can
say
that
schema
can
be
just
a
schema
or
schema
objects
can
be.
We
can
contain
also
an
object
that
contains
information
about
schema
format.
So,
in
the
end,
of
course,
it
all
depends
how
we
approach
it,
but
that
would
that
I
think
are
totally
two
different,
separate
things
like
a
problem
with
that.
C
Currently
in
the
spec,
you
can
use
only
Json
schema
in
components,
schema
object
and
the
other
one
is
XML
protobuf
XML
protobuf,
not
breaking
change
in
my
opinion
can
be
done
in
3.1
3.2,
but
this
one,
depending
on
the
reason
why
it
doesn't
work,
might
be
a
breaking
change
and
yeah
I
agree.
We
should
maybe
try
to
put
more
attention
to
it
and
drive
this
discussion
in
the
other
issue
to
see.
What's
the
what's
the
reason
and
what's
the
possible
solution.
E
D
D
E
Yeah
I
mean
like
xsd,
is
like
the
major
one,
but
I
mean
I
just
feel
like.
We
need
to
have
some
sort
of
generic
solution
for
it,
but
I
would
say
that
90
of
what
we're,
what
we
see
right
now
is
demand
for
XML.
You
know,
events
coming
out
of
sap
are
still
formatted
in
in
XML,
so
that's
pretty
important
for
what
we
deal
with
but
again,
I.
Don't
think
that
we
should
solve
it
only
for
XML,
but
more
more
generally,
because
I
do
think
that
those
those
cases
are
not
not
rare.
D
A
D
I'm
gonna
stop
I'm
gonna,
stop
sharing
sharing
my
video
today.
This
is
my
general
connection,
is
not
good,
so
I
was
saying
that
maybe
we
can
have
schemas
under
components
just
for
decent
schemas
for
the
default
ones.
If
you
want
and
other
components,
we
can
have
access
to
schemas
and
protobub
schemas
as
different
keys,
and
then
it
would
be
just
a
matter
of
the
parser
check-in
on
the
payload.
D
When
we
reference
something
from
the
components
we
will
check
if
it's
a
if
it's
referencing
a
decent
schema
or
or
a
product
above
schema
or
a
Nexus
schema,
and
this
way
we
can
make
differentiation
between
the
three
and
we
don't
have
to
support
more
because
I
never
hear
anything
about
the
any
other
format.
Avro
is
the
only
one
but
average
Json
so
average
is
not
a
problem.
Apples
will
be
easily
doable.
We
can
use
dollar
wrap
inside
our
as
well.
So
that's
completely
fine.
So
so
average
is
not
it's
not
really
a
problem.
D
We
can
still
have
another
section,
average
schemat
in
inside
inside
components
and
and
that's
it.
We
list
all
the
possible
schema
formats
that
we
support,
which
are
four
in
this
case,
and
that's
it
maybe
in
the
next
major
version,
we
find
a
cool
solution
that
works
for
all
of
them
without
having
to
separate
them
into
different
keys,
but
yeah
like
just
an
idea
that
we
probably
don't
have
to
yeah.
D
B
E
Yeah
I
mean
that's
tough
right,
you
know.
Maybe
you
have
a
link,
then
you
get
into
sort
of
like
you
know.
You
have
three
free
Fields
like
you,
have
a
schema
format
field
and
then
you've
got
like
an
outside
reference
field.
That's
not
dollar
sign
ref,
but
something
that
we'd
come
up
with
on
our
own
and
then
you've
got
like
the
inline
plain
text.
Schema
of
you
know
whether
that's
an
xsd
or
a
protobuf
definition,
or
something
like
that.
D
D
E
D
Yeah
yeah,
so
you
might
want
to
bundle
things
into
one
file
and
then
fit
it
into
some
of
the
tools
or
services
that
you're
using,
and
in
this
case
you
need
to
be
in
line
and
not
referencing
any
other
file.
So
but
but
yeah
like
in
lighting
is
not
really
a
problem,
because
the
only
problem
is
that
yeah,
it's
a
pain
to
to
edit
manually
but
yeah.
D
We
just
I
mean
the
tools
to
be
clear
about
it
like
right,
like
it's,
you
can
link
it
and
don't
edit
files
inside
this
field.
Here
you
don't
have
to
you.
You
can
lock
yourself,
but
but
if
you
want
to
still
export
it,
you
can
export
it
as
a
single
file
and
that's
preferable.
If
someone
wants
to
avoid
these
recommendations
and
inline
things
themselves
and
I
think
things
there
that's
their
problem,
but
but
yeah
and
the
reason
I
was
saying.
D
This
is
because
in
each
of
the
components
section
problem
above
schemas
other
schemas,
and
all
of
that
we
can
use
different
referencing
models
as
well
right
for
each
of
the
schema
for
each
of
the
schema
formats.
So
for
inside
protoba
schemas,
we
could
be
using
something
custom
that
will
be
give
me
the
URL
of
the
schema.
D
What
is
it
it's
a
file
on
my
system,
it's
somewhere
else
and
in
another
format
that
will
be
allowing
you
to
reference
a
specific
message
inside
inside
the
product
file
and
messages
can
be
nested
so
inside
specific
messages
in
a
specific
field
or
whatever,
whatever
it's
loaded
there
and
that's
for
product
and
for
xsd,
will
be
completely
different,
probably
Maybe,
not
maybe
not
so
different,
but
instead
of
referencing
with
dollar
ref
or
with
our
own
way
of
doing
it.
We
can
use
XPath,
for
instance,
which
is
standard
for
that.
D
So
so
we
can
use
expat
or
XML
preferencing
and
that's
my
point
like
we
don't
have
to
use
a
single
solution
for
all
and
at
least
not
in
the
beginning,
because
it's
not
easy.
It's
not
going
to
be
easy
right,
but
if
we
do
it
like
this,
we're
already
providing
value
right,
we're
already
providing
value
to
users
and
that
will
be
able
to
use
product,
buff,
xsd
and
everything
else
inside
the
async
API,
maybe
not
in
a
elegant
way.
But
who
cares
about
that?
Being
elegant,
yeah.
E
I
mean
I,
don't
care
about
Elegance,
but
I
do
care
about
tech
debt,
like
you
know,
if
we,
if
we
do
it
this,
if
we
do
it
this
way,
then
you
know
when
you
when
it
comes
to
when
we
do
it
for
real
and
think
about
it,
then
people
have
to
radically
change
both.
You
know
their
tooling,
both
Import
and
Export
sides.
So
yeah.
B
D
B
I
think
I'm
gonna
afford
the
because
we're
running
out
of
time,
I
think
I'm
gonna
create
a
specific
call
just
for
that
discussion,
maybe
not
in
the
next
following
weeks,
but
just
to
move
that
issue
along
or
proposal
along
because
it's
going
to
be
a
very,
very
complex
discussion.
I
think
many
different
and
what's
it
called
like
many
different
passes:
branches
yeah.
Exactly
that's.