►
From YouTube: Spec 3.0 meeting 1 (January 19, 2022)
Description
Sync on the work related to 3.0 release
https://github.com/asyncapi/community/discussions/157
A
A
A
C
A
I
think
we
will
just
start
it
off
and
see
what
happens
if
there's
anyone.
I
think
we
hit
a
limit
now
on
restream.
Unfortunately,
so
if
anybody
who
wants
to
join
or
ask
questions,
you
can
just
write
in
the
chat
and,
let's
see
what
happens,
but
apparently,
as
lucas
says,
we
have
professional
pen.
So
maybe
it's
not
a
problem.
It
just
gave
me
a
gave
me
a
warning,
so
I
don't
know.
A
A
And
yeah
otherwise,
we'll
just
follow
the
agenda
and
there
will
be
plenty
of
room
to,
of
course,
ask
questions
to
each
individual
again,
the
item
and
but
other
than
that
it's
there
will
be
no
decisions
on
this
meeting.
It's
purely
for
having
a
platform
to
talk
things
through.
That
might
be
a
bit
difficult
in
issues
or
comments.
E
A
A
A
A
F
I
mean
it
sounds
like
a
fantastic
idea.
I
guess
this
would
be
an
interesting
sort
of
use
case
for
me
to
understand
so
the
the
pr
is
opened
essentially
what
what
happens
next,
like
we
add
comments
into
it,
is
there
actually
some
sort
of
voting
process
or
how?
How
does
that
get
decided
to
move
forward.
A
A
F
No,
I
think
it's
entirely
the
right
approach,
I'm
just
wondering
you
know,
since
this
seems
like
a
really
great
thing
to
start
with
sort
of
the
restructuring.
It's
great
infrastructure
to
you
know,
allow
multiple
streams
to
work.
Potentially,
you
know
what
does
it
look
like
moving
forward,
so
we
can
use
that
as
a
baseline.
A
A
It
is
just
to
have
some
food
for
thought
for
later,
maybe
for
next
meeting.
You
have
some
questions
about
it,
so
it's
more
to
raise
awareness,
because
this
would
be
a
breaking
change
to
the
specification
and
if
we
can
include
every
as
much
as
possible
into
one,
that
would
be
preferable.
Of
course,
if
it
makes
sense,
I'm
going
to
link
the
issue
in
the
chat,
so
I
want
to
have
a
the
possibility
to
jump
in
and.
F
No,
no
questions,
I
think,
just
a
comment
that
you
know.
I
think
the
the
philosophy
of
this
is
pretty
important.
I
think
to
this
point:
we've
envisioned
async
api
as
sort
of
a
file
based
api.
In
other
words,
you
know
there's
one
api
and
that
gets
defined
within
the
file
and
it's
you
know
an
actual
physical
file.
F
You
know
this
is
my
personal
view
since
we're
you
know
here
to
discuss
things
and
I
think,
the
more
flexible
we
can
make
it
async
api
to
to
accommodate
various
different
ways
of
representing
async
api
beyond
just
having
a
file,
I
think
is,
is
better
and
I
think
we're
making
a
good
step
forward
with
these
sort
of
reusable
reusable
compo
components,
but
I
think
we
need
to.
We
need
to
spend
more
time
and
thought
about
how
to
how
to
push
even
further.
A
F
Sure
yeah
the
american
is
talking
the
most,
which
is
always
makes
me,
feel
a
little
self-conscious,
but
I
will
continue
to
talk
because
that's
what
we
do
so
I
will
say
I
do
think
you
sort
of
what
what
does
nascent
kpi
represent
and
how
do
what
are
the
various
manifestations
of
it?
I
think
it's
really
bedrock
concept
that
I
think
you
know
like
I
said
we
should
have
discussions
on
github,
certainly,
but
also,
I
think,
having
a
live
discussion
also
would
be
really
really
helpful.
F
I
think
another
real
bedrock
question
that
we
need
to
answer
is
perhaps
how
slavish
are
we
going
to
be
to
to
json
schema,
and
I
know
that
we've
got
a
couple.
Json
schema
experts
on
here,
which
I
think
is
fantastic.
I
know
that
you
know
just
drawing
from
the
open
api
experience.
It
seems
like
they
diverged
from
json
schema
pretty
significantly
and
seemed
to
have
regretted
that
you
know
kenzon
on
the
on
the
call,
and
maybe
he
can
speak
to
his
experience
there.
D
No,
I
mean
I
can
speak
to
it.
I
would
I
would.
I
would
frame
it
more
as
bending
the
json
schema,
rather
than
moving
away
from
json
schema,
we
bent
it
and
and
didn't
stick
to
it,
which
caused
a
lot
of
pain
and
suffering
for
everybody
involved,
and
then
we've
gone
back
to
it
and
supporting
the
the
latest
latest
draft.
D
So
open
api
and
async
api
are
considered
vocabularies
of
json
schema,
so
there's
there's
also
like
forms
vocabularies,
so
json
schema
core
is
meant
for
validation.
Now
the
majority
of
folks
view
it
as
as
as
a
modeling
specification,
but
it's
it's
and
it
is
used
for
that
in
reality,
but
that's
not
it's
its
sole
intended
purposes.
It's
intended
purposes
for
validation.
So
when
you
start
using
it
for
alternate
purposes
in
this
way,
it's
it
falls
under
the
the
umbrella
of
vocabularies
and
that's
what
async,
api
and
and
open
api
currently
are.
F
G
Yeah,
I
can
talk
a
bit.
I
don't
have
all
the
insights,
but
I
have
experienced
some
things
lately
about
it.
So
I
investigated
a
bit.
We
are
using
draft
7
right,
correct
me
if
I'm
wrong
and
there
have
been
several
drafts
after
it,
and
there
are
like
a
couple
of
issues
I
think
matcha
created
in
order
to
move
forward
and
keep
up
with
latest
persons
what
happened
in
there
is
that
with.
G
When
I
say
we,
it's
john
as
an
I
that's
why,
if
you
check
the
block
on
on
a
sync
api,
you
will
see
that
jonas
wrote
a
blog
post
about
it,
so
we
went
down
to
a
rabbit,
hole
investigating
about
it.
What
is
our
real
usage
of
json
schema
and
what
features
are
we
using
and
we
are?
We
realized
that
there
are
some
things
that
we
are
not
even
using
from
json
schema.
We
are
not
aligned
with
even
draft
seven.
We
don't
use
all
the
potential
json
schema
provides
right.
G
G
B
B
I
created
a
few
months
ago
the
idea
how
to
solve
the
problem
to
reference,
the
another
schema
format
than
json
schema,
avro
and
ram,
and
the
other
that
we
at
the
moment
support
like
the
xml
schema
definition
or
graphql
or
protobuf
in
our
ascent
api
yeah
yeah.
Exactly
and
the
main
problem
at
the
moment
is
that
we
don't
have
the
clarification,
how
exactly
the
referencing
worked
in
the
essence
api.
B
Like
the
string,
the
normal
string
and
it's
very
important,
for
example,
for
x
as
that
or
grab
coil,
because
you
cannot
reference
the
xsdf
format
or
grab
coil
types
inside
the
json,
it
will
be,
it
will
be
referencing
as
as
the
string-
and
this
is
the
main
problem
of
this
proposal,
how
exactly
the
reference?
The
references
works
inside
the
essence,
api
yeah.
F
That's
interesting,
I
think
sorry,
I
want
to
make
sure
I
was
on
mute.
I
think
that's
you
know
from
my
perspective,
a
really
big
thing
you
know
both
for
solace
but
who
I
represented
myself
coming
with
my
experience
like
async
communication
frequently
involves
things
that
it's
not
json,
so
to
be
able
to
expand
out
into
that
world.
B
B
F
D
H
D
Or
any
other
realms,
yeah
or
even
xml,
so
so
it's
it's
a
pretty
pretty
narrow
view
right
now
and
I
don't
think
there's
a
I
haven't
seen
any
champions
looking
to
go
beyond
it
beyond
the
async
api
for
casing.
Kpi
api
specifications
conference,
which
is,
is
meant
to
be
a
multi-specification
and
and
bring
in
across
all
of
the
the
the
specs
and
and
leveraging
the
linux
foundation
to
do
it,
but
it's
not
about
bringing
bringing
that
into
the
specification
itself.
A
The
only
cavity-
and
this
is
where
we
have
as
an
advantage,
I
would
say,
is
that
we
have
tooling
with
us,
because
one
of
the
issues
is
that
as
soon
as
you
allow,
multiple
different
schema
formats
to
be
defined
tooling
has
to
handle
it.
If
you
had
to
have
code
generational,
parsing
or
ui
document,
and
if
you
have
a
ui
that
wants
to
render,
for
example,
how
a
payload
should
conform
to,
then
you
need
to
know
the
format
or
you
need
to
handle
it
some
other
way.
A
A
F
Well,
that
raises
an
interesting
question
and
I,
like
that
perspective,
so
is
it
the
case
where
we
actually,
instead
of
defining,
do
we
do?
We
need,
like
a
format
binding
in
addition
to
like
protocol
bindings,
you
know
the
avros
and
the
buffs
of
the
world
aren't
the
last
thing
to
emerge.
Certainly,
there's
going
to
be
more
and
there's
already
a
billion.
You
know
protocols
out
there
is
this
something
that
we
need
to
support
instead
of
hard
coding
or
just
treating
as
strings.
F
C
We
need
a
way
that
doesn't
push
all
this
down
to
individual
tooling,
like
there
is
a
benefit
to
having
json
schema,
lowest
common
denominator.
So
individual
tools
don't
need
to
worry
about
it,
though
they
deal
with
a
consistent
schema,
so
yeah.
I
think
if
we
can
come
up
with
the
way
that
a
plug-in
based
approach
would
achieve
that
same
goal
of
not
pushing
complexity
to
every
individual
tool,
to
do.
Okay,
that
that
would
be
good,
but
I
think
that
would
be
an
important
requirement.
F
H
Yeah
I
mean,
I
think,
there's
only
so
much
we
could
do
with
plug-ins
at
the
spec
level.
If
that's
what
you're
talking
about,
I
mean
when
I
think
of,
for
example,
the
code
generator.
I
worked
on
the
java
spring
cloud
stream
generator
in
order
to
support
xml,
for
example.
You
know
I
mean
I
could
do
it.
I
could
just
have
to
say
well,
okay,
this
document,
it's
pointing
to
the
xsd
schema,
and
I
know
how
to
do
that
in
java.
H
I
know
how
to
call
you
know:
there's
there's
libraries
that'll,
read
the
xsd
and
generate
the
generate
the
appropriate
java
class.
It
represents
that,
but
I
mean
at
some
point
like
that
has
to
be
done
at
the
tooling
level.
I
think
I
don't
think
there's
any
place
in
like
our
parts
or
other
tools
that
could
do
that
for
us.
So
I
think
you
know
at
some
point.
The
rubber
hits
the
road
and
you
know
whatever
generator
or
other
downstream
tools
want
to
accommodate
these
different
schema
types.
They
they
will
have
to
do
some
work.
H
H
F
H
Yeah
yeah,
that's
why
we
have
to
have
something
else:
that's
not
like
a
json
reference
to
another
file.
It
has
to
be
something
that
you
know
is
opaque.
As
far
as
json
goes
and
says,
this
is
just
a
link
to
some
external
file.
Don't
try
and
read
it.
Don't
try
and
parse
it,
because
you
won't
be
able
to
right.
F
H
B
Clarify
this
behavior
with
reference
only
yeah,
because
also
inside
this
idea,
I
have
the
idea
how
to,
for
example,
add
the
additional
options
to
the
given
parser
for
avlo
xml,
etc.
So
maybe
the
problem
for
you,
michael
will
be
something
like
that
that
you
exactly
add
the
reference
to
the
given
file,
but
also
at
the
options
please
download.
H
F
There
so
it's
like,
I
guess,
which
seems
to
me
to
because
you
know
we're
going
to
run
across
these
sort
of
idiosyncratic
things
for
each
format.
Maybe
that
points
to
sort
of
a
format,
binding
kind
of
thing
where
you
know
we
don't
have
87
different
options
that
you
know
they're
just
one-offs
for
xml,
one-off
for
protobuf,
but
rather
you
have
this
sort
of
bindings
to
protobufs,
and
that
includes
the
that
includes
the
the
options
you
need
potentially
to
understand.
The
protocol.
B
H
E
I
got
a
question
about
the
schema
stuff
so
proposal
to
allow
defining
any
schema
format.
We
get
a
lot
of
feedback
from
the
community
that
they
don't
like.
You
know
the
other.
The
default
schema
format
just
out
of
interest.
I
I
like
where'd,
the
idea
originate
from
and
what
who's
like
and
kind
of
what
group
of
people
are
pushing
that
or
is
it
the
group
or
is
it
the
people
here?
If
you
see
what
I
mean
just
out
of
interest,
yeah
yeah.
F
I'll
I'll
talk
so
we've
got,
you
know
a
number
of
people.
You
know
in
the
healthcare
space
you
know,
healthcare
is
still
using
edi
30
years
later
and
so
there's
you
know,
we
have
healthcare
clients
that
are
like
well.
Why
can't
we
define
edi
document
with
with
with
async
api
that
sucks,
then
we've
got
people
that
are
taking
information
out
of
sap
and
that's
an
xml
and
they're
like
well
what
the
hell.
Why
can't?
I
can't
wait
to
find
the
xml
payload
you
know
and
like.
H
F
E
F
F
I
think
that's
that's
important
and
I
think
fran
has
pointed
to
sort
of
a
a
confusion
about
local
and
remote
bindings
that
I
disagree.
I
I
I
think
that
should
be
solved
without
with
within
the
binding
by
the
the
bindings
themselves,
but
I
think
that's
an
important
thing
for
us
to
work
out
as
as
a
community.
F
Let's
just
see
friends,
friends
comment
there
and
then
I
think
the
sort
of
the
the
object
reuse
so
that
I
think
you
know
we're
sort
of
moving
in
that
direction.
Anyway.
The
multi-protocol
support
would
be
on
on
my
list
and
again
this
isn't,
like
you
know.
I
don't
think
by
any
means
is
my
my
definitive
my
list
definitive,
but
I
just
wanted
to.
F
And
what
takes
priority
when
you
do
that.
So
that
would
be
my
priority
list.
That
was
not
the
intent
was
not
to
say
like.
This
is
what
jesse
thinks
should
be
a
priority,
and
this
is
more
just
like
a
placeholder
to
say
that
we
should
at
the
outset,
try
to
come
up
with
some
things
that
we
think
are
are
important
for
us
to
to
conquer.
A
I
wanted
to
quickly
highlight
something
so
currently
we
do
have
a
milestone
in
the
spec
repo
that
has
all
of
the
issues
that
we
think
might
need
to
be
reconsidered
or
considered
for
3.0
release.
It
contains
all
of
the
issues
that
might
be
a
breaking
change
in
the
future
or
would
require
breaking
change.
Maybe-
and
these
are
kind
of
all
of
the
issues
that
we
try
to
bundle
together,
there
can
be
new
ones
that
can
be
they
can
be
removed
once
resolved
or
once
a
decision
is
reached,
but
we
still
follow
the
contribution
guidelines.
A
A
A
Oh
yeah
dale
who's
running
the
the
2.3
release
at
the
moment
added
this
work
on
2.3
release
and
I'm
I
love
this
idea
of
having
everything
within
one
issue
more
or
less
like
the
progress
who
is
working
on
which
issues
who
are
driving,
who
are
championing
issues
through
right
so
as
soon
as
2.3
is
done,
or
maybe
also
just
after
this
meeting,
I
maybe
it
makes
sense
to
make
this
issue
to
track
what
is
happening.
What
is
what
needs
to
be
done?
What
is
still
missing?
F
G
G
G
C
C
A
One
point
to
that
is
it's
kind
of
difficult
in
many
cases,
for
example
the
meaning
just,
for
example,
the
meaning
of
facing
on
an
async
api
file.
It
depends
on
what
level
you
want
like
to
solve
it,
that's
the
problem.
Many
of
these
issues
are
well,
we
can
do
a
breaking
change,
and
this
would
require
this
and
this
and
this,
but
we
can
also
do
the
non-breaking
one
and
it
all
depends
on
the
use
cases
and
specifics.
F
Yeah,
well,
I
I
agree
with,
I
think
everything
that's
been
said
and
I
do
think
opening
it
up
to
the
community
and
obviously
the
people
who
are
on
this
call,
I
think,
are
probably
the
most
vested
or
at
least
have
shown
the
most
interest.
So
you
know,
let's
say
and
maybe
commit
that
before
the
next
meeting
we
actually
go
through
and
sort
of
do
a
triage
on
on
those
those
issues.
G
Sense
saying
something
there
in
the
chat
that
I
don't
quite
understand
so
fran
you're,
saying
that
all
these
should
be
considered,
which
doesn't
mean
that
they
have
to
be
in
b3,
okay,
but
you're,
saying
before
we
release
v3.
We
have
to
look
at
all
of
them
and
make
sure
they
are
not
introducing
breaking
changes.
A
I
think
what
he
means
is
that
the
issues
that
are
linked
on
that
specific
milestone
does
not
mean
that
they
have
to
be
introduced
in
order
to
release
3.0,
because
some
of
them
can
be
fixed
or
solved
using
a
non-breaking
change.
But
in
order
to
know
that
we
still
have
to
dive
into
and
kind
of
reflect.
H
H
A
H
F
G
G
I
don't
know
how
to
express
this.
How
many
breaking
chains
we
want
to
add
in
there.
Just
to
I
mean
I
don't
want
to.
I
don't
want
to
have
like
users
to
say
yeah,
I'm
gonna
give
up,
because
moving
from
2
x
to
3x
is
like
super
hard.
I
know
we
are
going
to
build
some
tool
around,
but
b3
adoption
should
be
either
like
a
pain.
You
know,
so
I'm
wondering
if
we
should
somehow
set
a
line
like.
G
E
Yeah,
sorry
yeah.
I
think
it
comes
down
to
what
jesse
and
dale
said
like.
I
think
you
need
to
set
a
scope,
because
if
you
don't
set
a
scope
in
a
line,
then
okay
we'll
accept
everything.
Okay,
so
who's
triaging!
There's
you
know,
I'm
I'm
looking
at
this
list
now
and
there's
stuff
from
2018
and
I'm
like.
Okay,
I
want
to
know
how
is
that
mate?
For
example,
I
don't
know
how
has
that
made
the
list?
Is
it
still
relevant
because
it's
gonna
be
quite
difficult
to
it's
gonna
be
step
one!
E
It's
going
to
be
hard
to
just
identify
the
scope
of
this
thing
and
I
think
I
think,
even
harder
to
to
probably
say
what
we're
not
going
to
do
right
to
actually
say.
Okay,
we
know
that's
a
problem,
but
this
might
just
have
to
wait
for
a
minute
or
two
I
don't
know,
but
as
dale
said,
you
know,
I
agree
with
what
they
were
saying
about.
E
You
want
if
we
probably
want
to
use
the
opportunity
for
the
three
release,
because
you
have
to
wait
so
many
months
for
a
fall
right
so,
but
I
think
it's
key
so
yeah
what
you're
saying
is.
Definitely
we?
Surely
we
have
to
have
a
line
like
any
kind
of
project
right,
it's
just
to
define
the
scope
to
find
what
we
want
to
do
somehow,
and
this
might
be
the
hardest
thing
because
kind
of
like
grooming
50
tickets.
It's
like
I
don't
know
how
you
do
that.
E
A
I
think
at
the
moment
it's
just
a
milestone
and
it's
anything
can
be
added
to
it
at
the
moment,
because
there's
no,
maybe
clear
vision
for
it.
For
that
specific.
But,
as
fran
also
said,
like
pops
up
confusion,
channel
reusability
and
many
meanings,
that's
some
of
the
core
issues
that
tries
to
be
solved.
It
doesn't
mean
that
new
features
needs
to
be
added
as.
F
Got
well
well,
I
mean
it's
interesting.
Luke
is
what
lucas
is
bringing
up
here
and,
first
of
all,
fran.
Thank
you
for
thank
for
celebrating
the
fact
that
you
convinced
me.
That's
awesome.
I
think
yeah
we've
got
eight
minutes
left,
and
maybe
this
is
the
point
where
we
talk
start
talking
about
what
we're
gonna
do
in
the
interim.
I
guess
my
proposal
would
be
that
every
two
weeks
is
probably
not
going
to
be
enough
to
sustain
momentum
on
this,
especially
from
that's
important.
F
So
I
guess
my
proposal
will
be
to
move
this
meeting
to
weekly.
I
know
it's
a
pain
in
the
butt
and
I
I
don't
want
to
have
more
meetings,
but
this
discussion,
I
think,
is
really
really
important
and
it
has
been
just
today
has
been
really
fun
and
useful
for
me,
so
I
would
first
propose
that
and
second
to
have
some
sort
of
system
a
systematized
way
of
us
all,
commenting
on
each
of
those
milestones,
each
of
those
things
within
the
milestone.
A
G
G
So
what
is
left
on
the
tickets
I
created
for
3.0
is
one
ticket
that
basically
was
making
channels
feel
optional
on
the
whole
async
api
file.
This
was
aiming
to
be
in
2.3,
but
thank
you,
jonas,
because
you
discovered
this
was
breaking
change,
so
is
postponed
for
3.0.
If
it
makes
sense
by
then
then
there
is
another
one
that
it's
letting
channels
to
be
identified
by
id,
rather
than
their
address,
which
is
basically
adding
so
reusing.
G
We
can
discuss
about
it
on
the
on
the
issue,
but
what
I
wanted
to
rise
and
you're
gonna
like
it,
just
see
it's
the
remote
and
local
servers
stuff.
So
how
can
we
tackle
this
right?
So
I
created
a
new
issue,
so
we
can
discuss
properly
instead
of
using
the
pops
up
one
because
it's
getting
so
it's
like
a
mess
right
now
to
discuss
in
there.
G
G
E
So
3.0
spec,
there's
going
to
be
quite
big
things
that
are
changing,
yeah
and
big,
big
ideas
and
big
things
to
consider
which
take
a
long
time
to
digest
right,
a
long
time
to
read
and
think
about
and
even
understand,
and
for
me,
it's
quite
difficult
to
sometimes
quite
difficult
to
gain
context
in
the
issues
and
stuff
and
like
like
when
they're
small,
it's
okay.
But
when
you
talk
about
massive
changes,
it's
like
really
hard
just
to
understand.
So
I
don't
know
if
we
should
use
these
kind
of
meetings
in
the
future
too.
E
What
I'd
like
to
see
is
like
go
into
these
like,
for
example,
if
we,
if
we
use
next
week's
meeting
or
whatever,
and
I'm
not
sure
how
this
would
work
and
that's
why
I'm
asking
for
feedback,
but
we
could
dive
into
the
remote
and
local
servers
issue
yeah
as
a
whole
hour
where
we
just
talk
about
okay.
This
is
why
I
started
literally
from
the
top
like
no
one's
heard
this
stuff
before
right.
This
is
what's
happening
now.
E
This
is
why
I'm
recommending
this
and
let's
discuss
and
then
the
discussion
is
recorded,
we
can
share
it
and
then
we
can
write
up
our
thoughts
on
the
issue
afterwards.
So
we
have
two
forms
of
communication.
One
is
the
issue
for
historic
and
one
is
just
for
open
discussions,
because
I
think
it's
a
lot.
Sometimes
it's
a
lot
easier
in
these
big
big
things
to
come
on
stream.
C
It
would
be
a
lot
more
work
for
the
person
who
had
something
to
the
agenda
because
they're
going
to
have
to
distill
that
long
meandering
issue
down
into
his
the
the
nub,
but
it
would
definitely
make
conversation
and
debate
easier
because
of
that
time
invested
in
distilling
it
down.
So
if
people
are
willing
to
do
that
kind
of
prep,
I
absolutely
think
it
would
make
these
calls
more
effective.
C
G
A
But
yeah,
maybe
just
to
give
a
notice,
so
everyone
is
welcome,
and
this
is
just
to
emphasize.
Everyone
is
welcome
to
start
a
meeting.
Everyone
is
welcome
to
start
a
stream.
I
mean
it's
it's
open
for
everyone
to
do
whatever
you
feel
is
necessary
to
make
make
awareness
of
a
specific
issue
or
discussing
something.
It's
just
reaching
out
start
a
discussion.
The
same
way
I
did
with
3.0
and
then
get
access
to
it.
Sorry,
but
yeah.