►
From YouTube: Spec 3.0 meeting (April 27th, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
B
B
There's
not
much
today,
apparently
so
jonas
couldn't
join
today
and
he's
the
one
running
these
meetings.
So
I'm
just
gonna
stick
to
the
agenda
which
is
empty,
so
I
don't
know
only
question
and
answer.
So
if
someone
has
any
question
or
any
answer
just.
C
B
Actually,
I
think
the
progress
with
the
parser
is
also
interesting
for
spec
3
0.
If
I'm
skinner
related
right,
so
I
don't
know
how
yeah
how's
it
going.
You
might
want
to
just
give
a
brief
overview
of.
C
Maybe
magic
was
a
the
one
who
worked
lately,
because
I
was
more
involved
on
2.4.
I
don't
know
if
you
want
to
share
something.
Otherwise
I
mean
I
can.
D
We
have
at
the
moment
new
base
model,
the
collection
model
which
exactly
works
on
the
ri
and
the
object
side,
and
this
will
also
help
us
to
rewrite
the
servers
and
the
servers
variables
and
the
server
requirements,
the
security
requirements
and
I
I'll
sort
of
wrote
some
functions.
Some
helpers
to
stringify
to
validate
the
parse.
I
also
integrate
the
the
spectral
inside
the
parser,
but
first
you
need
to
write
the
rules
for
the
parser
in
the
personal
repository
yeah.
So
I
also
create
the
blue
request,
but
we
need
to
review
and
merge
that.
D
E
D
D
We
have
also
the
info
object,
but
we
need
the
channels
and
operation
that
messages
them,
because
at
the
moment
we
split
the
definition
to
separate
cholesterol.
B
A
D
D
B
D
A
issue
with
the
list
of
the
issues
that
we
have
that
we
try
to
try
to
fix
on
the
next
major
version
of
the
person
yeah.
D
D
Exactly
if
someone
want
to
contribute,
please
write
in
this
issue
in
the
comments
and.
B
Also
yeah,
but
together.
D
A
B
B
Okay,
so
so
do
is,
if
you
want
to
participate,
that's
fine!
So,
but
if
you
want
to
stay
on
the
chat,
that's
also
that's
also
cool,
as
you
prefer
so
he's
saying
that
he's
new
to
amazing
kpi
and
joining
as
a
contributor
for
the
google
season
of
docs
program
would
love
to
ask.
How
will
this
meeting
improve
my
understanding
of
facing
kpi?
So
this
meeting
is
actually
not
for
understanding
async
kpi,
but
this
is
a
meeting
that
we
run
every
two
weeks
to
work
on
the
next
major
version
of
the
spec.
B
So
spec
is
right
now,
actually
right
now
was
released
as
2.4.0
version
and
we're
working
on
the
3.0,
which
is
gonna,
take
a
while,
probably
until
the
end
of
the
year,
or
something
like
that,
so
so
yeah.
That's.
Why
we're
running
these
meetings
to
coordinate
efforts
towards
version
3
of
the
spec
yeah,
so
sergio
is
sharing
more
details
there.
I'm
gonna
pass
it
on.
B
There
as
well,
yes,
so
yeah.
That
is
that's
what
it
is
so
this
if
you
want
to
learn
about
async
api
and
understand
a
little
bit
better.
We
run
a
community
meeting
every
two
weeks
as
well,
and
it's
next
week,
it's
happening
next
week
on
tuesday
at
4,
00
p.m.
Utc!
I
think
it's
still
not
in
the
calendar
but
yeah.
B
B
B
So
I
think
there
is
nothing
there's
nothing
left.
I
think
so.
This
one
is
the
release
this
one
yeah.
This
is
the
right.
B
B
I
I
just
had
a
chat,
as
you
may
know,
with
lauren
from
mike
rocks,
I'm
thinking
out
loud,
and
we
actually
were
talking
about
the
change
of
the
meanings
of
the
verbs
now
send
and
receive,
and
then
and
now
they
mean
what
they
do
and
know
what
you
can
do
with
the
application
and
blah
blah
blah.
You
know
change
of
perspective
of
public
subscribe
and.
B
This
is
a
request
right.
It
is
not
any
kind
of
message
that
is
sent,
so
we
give
it
more
semantics.
Let's
say:
does
it
make
sense?
What
I'm
saying
or.
B
And
we
were
just
discussing
that,
maybe
as
an
idea
right,
maybe
something
that
we
could
be
doing
is
that
we
add
another
verb
to
separate
right
to
differentiate
between
sending
and
receiving
like
generic
sending
and
receiving
and
making
it
more
explicit
that
for
requests
for
apis
for
traditional
apis.
Let's
say:
client
server,.
B
C
Yeah,
I
I
remember
we
discussed
about
this
when
we
started
designing
the
intent
api.
In
fact
I
I
cannot
remember
how
can
I
look
for
the
issue,
but
it
should
be
somewhere.
C
That
we
included
different
verbs,
not
only
yeah
polish
and
subscribed
by
them,
but
some
others,
like
I
don't
remember,
which
one
were
more
focus
on
http
and
website.
I
think
yes,
I
think
so
so
those
will
become.
I
guess.
B
B
B
Without
without
any
well
actually
no
no,
it
cannot
be
like
this,
because
if
it's
a
web
circuit,
then
it
doesn't
match
but
yeah.
B
But
something
like
this
something
like
you
have
request
and
then
inside
you
have
the
definition
of
the
request,
whatever
fields
for
defining
the
request,
right,
description,
summary
and
all
this
stuff,
and
you
will
want
to
define
the
payload,
of
course,
of
the
body
of
the
request
and
the
headers
and
so
on,
right,
which
is
in
in
other
words
it's
the
message
that
you're
gonna
send
right
and
and
potentially
also
another
section
inside.
B
But
for
version
3
we're
saying
that
the
clients
will
have
its
own
async
and
document.
So
it's
you
don't
use
the
one
of
the
server
for
version
three.
We
agreed
that
you
should
have
one
for
the
server
and
one
for
the
client.
Okay.
So
that's
that's
why
you
don't
have
to
do
this
anymore.
B
B
E
B
C
Unfortunately,
sorry
I
don't
know
if
you
mentioned
that
so
most
of
the
bindings
on
http
could
go
into.
C
B
C
C
B
Suvik
is
currently
making
the
http
binding
an
open
api
object
so
like
exactly
an
open
api,
which
makes
more
sense.
So
we
don't
reinvent
the
wheel
and
actually
it's
there.
It's
described
there,
but
we
it's
described
everything
that
you
can
do
there,
but
we
could
probably
just
say
on
the
http
http
binding.
We
could
just
say
this
is
an
open
api
path,
item,
object
and
point
to
open
the
paper
rotation.
B
So
so
yeah,
that's
why?
But
it's
kinda
weird!
Now
as
it
is
because
yeah
it's
kind
of
weird
because
you
have
you-
should
only
be
able
to
to
use
the
http
binding
on
the
subscribe
operation
right
or
on
the
publish
operator
confused
on
the
public
operation
on
the
publish
operation.
B
D
And
but
do
you
say
that
some
companies
want
to
you
know
hide
some
internal
things?
Yes
on
the
specification,
but
if
someone
want
to
only
expose
some,
you
know
the
channels
that
people
can
subscribe
by
the
websocket.
So
what's
done
so
they
probably
should
create
another.
You
know
something
like
the
private
essence:
api,
the
public
essence
api
to
the
subscribe
and
then
the
client
to
the
request.
B
You
make
it
reference
the
product
one
or
something
like
that,
and
then
you
bundle
it
before
you
share
it
right
yeah.
So
it
doesn't
have
any
references,
but
you
probably
have
to
maintain
two
because
say,
for
instance,
the
description
right.
If
in
a
description
you
have
like
something
saying
something
like
this
is
sending.
B
This
is
sending
a
message
to
the
broker
to
create
a
user
whatever
right-
and
this
is
on
the
private
side-
let's
say
on
the
implementer
side
on
the
client
side
on
the
consumer
side,
this
comment
doesn't
make
sense.
B
I
call
my
operation
id
on
user
signup,
for
instance,
because
I
want
to
use
the
this
operation
id
on
on
the
generated
code
on
user
sign
up
on
user
sign
up
on
the
server
side.
Let's
say
it's
fine,
but
on
the
client
side
it
will
be
on
user
signup.
It
should
be
send
user
sign
up
right
when
one
is
receiving
the
other
sending
right.
So
if
so,
the
operation
id
doesn't
make
sense
to
be
reused.
B
D
D
D
And
then
yes,
I
mean
we
can
also
go
in
this
direction
to
create,
maybe
something
like
the
extension
to
describe.
You
know
something
like
the
switching
that
you
exactly
write
everything
from
the
application
point
of
view,
but
then
for
the
given.
You
know
the
the
also
the
operation
of
the
channels
right.
B
It
also
has
all
it
also
has
other
other
problems
say,
for
instance,
internally,
I
might
be
subscribing
to
the
broker
on
a
broker
topic
to
receive
a
message.
Oh.
D
B
But
the
client
might
not
be
talking
to
the
broker
directly,
they
might
be
calling
an
http
endpoint
somewhere,
and
then
this
httpa
api
will
publish
to
the
broker
right.
So
you
can
you
can
that
that's
one
of
the
problems
that
we
have
right
now
we're
assuming
that,
just
by
changing
the
verve
everything
works
yeah
in
some
cases
it
does
in
some
cases
you
don't
it
doesn't
it
doesn't
work.
B
A
common
use
case
is
a
kafka.
Confluent
kafka,
http,
connector
right
you,
your
internal
application,
subscribes
to
kafka,
broker
the
topic.
What
your
clients
might
be
publishing
to
the
http
connector,
not
to
the
not
to
the
broker,
so
so
yeah.
So
it's
not
just
a
matter
of
changing
the
birth.
It's
you
have
to
change
everything
like
there's
a
new
server.
It's
a
new
protocol.
B
It's
it's
a
new
everything
is
new,
so
you
have
to
maintain
too.
So
I
think
the
easiest
one.
The
easiest
thing
that
we
can
do
here
is
that
don't
assume
that,
from
the
from
one
definition
you
can
infer
the
other.
Let's
not
assume
this,
because
it's
not
always
possible.
E
Sorry,
my
background's
a
little
messed
up,
my
green
screen's,
not
in
the
right
place,
etc.
The
background
looks
perfect.
It
makes
it
eclectic.
It
makes.
E
And
virtual,
so
I
I
didn't
want
to
interrupt
because
I'm
not
as
as
deep
to
where,
where
your
team
is
on
spec
3.0
but
but
super
interested,
and
I
know
that
you
know
my
work
with
the
nats
community
in
india
I
mean
we
are.
E
And
so
it
does
kind
of
resonate
that
in
terms
of
a
contract
or
an
interface
document,
there
really
is
sort
of
two
in
the
at
least
two
independent
documents:
the
the
relationship
that
the
broker
has
with
the
service
responder
and
the
relationship
that
the
service
requester
has
with
you
know,
broker
the
broker
in
terms
of
what
is
being
exposed.
E
A
B
And
then-
and
you
don't
know
how
the
topology
is
going
to
look
like
between
the
publisher
and
the
subscribers.
So
so
that's
that's
that's
the
thing
like
we
cannot
assume
that
publishers-
and
subscribers
are
always
just
connected
to
the
same
broker
right
so
subscriber-
might
be
connected
to
a
different
broker.
B
That
is
somehow
federated
with
a
second
broker,
which
is
where
the
the,
which
is
where
the
publisher
is
publishing
to,
and
they
don't
even
have
to
talk
the
same
protocol
like
you
said
so
so
so
that's
that's
also
a
common
common
case.
B
Actually,
two
weeks
ago
I
had
the
pleasure
to
talk
to
to
dominique
over
meyer
from
hyphen
q
on
the
thinking
out
loud
and-
and
he
was
actually
explaining
this
to
me
that
in
iot
this
is
very
common,
that,
on
the
edge
on
the
factories
on
you,
know
on
the
edge
they
implement
mqtt
brokers.
B
From
the
from
the
mqtt
broker,
so
so
what
happens
is
that
yeah
subscriber
here
might
be
reading
kafka
and
the
publisher
might
be
publishing
on
the
mqtt
brokers.
There.
E
Yeah
absolutely
like
that
server
now
has
it
can
exposes
mqtt
to
a
certain
set
of
connected
clients.
E
C
B
So
yeah,
that
is
an
assumption
that
we
cannot
make
so
so
moving
forward
is
yeah.
Maybe
you
said
he
was
right
like
from
the
client
perspective.
If
you
want
to
send
a
request,
it's
a
send
operation.
You
want
to
send
a
message
to
an
end
point,
but
but
yeah
it
will
be
cool.
If
we
could
have
semantics
that
this
send
operation
is
actually
a
request.
E
And
actually
I
you
guys
are
probably
way
in
again
my
apologies.
They
don't
want
to
come
in
and
say
dumb
things,
no
problem,
but
I
do
we
do
we.
So
much
of
this
seems
to
be
about
roles
and
actors
and
then
getting
the
right
names
and
semantics
that
everyone
feels
comfortable
with
about
those
those
actor
roles.
E
So
you
know,
sir,
you
know
I'm
a
service
responder
but
technically
to
the
broker
from
the
broker's
perspective.
I'm
just
another
client,
but
I
am
a
client
that
is
client
of
the
broker
that
is
taking
on
the
role
of
the
of
the
service
or
of
the
service
responder
in
the
in
the
interaction.
E
Same
way,
if,
if
I'm
a
service
client,
I'm
just
another
client
to
the
broker's
perspective,
but
I'm
taking
on
the
role
of
service.
A
B
E
B
B
Up
until
now,
we've
been
treating
in
broker-based
architectures,
we've
been
treating
them
all
of
them,
like
provider
and
consumer
server
and
clients,
and
something
like
that
and
it's
like
they're
all
clients.
E
Talking
about
immediately,
I
I
guess
I
could
just
talk
the
most
intimately
about
gnats
that
client,
who
is
the
service
requester
or
service
consumer
in
that's
it
to
get
the
asynchronous
service
reply?
It's
it's
immediately,
a
service
as
well
right
because
it's
sitting
there
listening
on
a
a
reply
channel
that
did
it
self-defined.
E
So
it's
almost
like
as
soon
as
the
request
goes
out.
Technically
the
roles
change.
They
flip
immediately
flip
for
the
reverse
channel
right,
yeah.
B
So
yeah
anyway,
this
is
just
was
just
food
for
thought,
like
we
don't
have
to
include
this
in
version
3.0.
Of
course.
This
is
something
that
we
can
be
included
in
strip
3.1,
maybe
3.2
or,
if
at
all
right.
So,
but
this
is,
I
just
wanted
to
mention
that
we
had
this
chat
today,
which
is
related
to
3.0
and
the
change
of
the
verbs.
B
So
at
least
we
covered
with
this
this
thing
about
having
two
async
ebay
documents,
one
for
let's
say
one
for
the
server
and
one
for
the
client
or
one
for
each
client
we're
covered
like
we
don't
have
to
do
these
weird
tricks
anymore.
B
Responsibility
is
delegated
to
the
user
that
they
will
have
to
create
two
ways
in
kp
documents,
but
I'm
confident
that
we
will
be
able
to
provide
some
tools
that
will
make
the
process
easier
right.
So
things
like
from
this
async
api
document,
please
infer
this
other
sync
api
and
for
those
who
are
doing
the
use.
The
typical
use
case
that
publisher
is
published
into
a
broker
and
subscribers
is
subscribing
directly
to
the
same
broker
of
the
same
topic.
B
For
those
it
would
be
just
a
command
and
they
they
get
it
flipped
they
get
the
birds
flipped
and
and
that's
it,
that's
something
and
they
will
be
asked
about
operation,
id
and
descriptions
and
so
on
just
to
check
if
it
still
makes
sense
and
that
could
work
studio
can
take
care
of
ad
cli
can
take
care
of
this,
so
so
that
could
be
that
could
be
provided
but
yeah,
at
least
we
don't.
We
don't
make
this
assumption
on
the
spec,
because
then
it
becomes
brittle.
B
E
B
We
actually
had
a
chat
on
thinking
out
loud
last
week
about
it,
but
thing
is
that
it
could
be
a
separate,
spec,
easily
separate
kind
of
document.
Call
it
whatever
you
want,
but
a
separate
spec.
So
that
is,
you
should
be
able
to
include
maybe
reference
different
types
in
key
paid
documents
and
give
them
roles,
for
instance,
and
roles
can
be
defined
by
you
like
this
is
a
server.
This
is
a
client.
B
E
And
then
I
guess
overall,
with
async
api,
is
it
trying
to
target
both
the
sort
of
broker
and
broker-less
kind
of
scenarios
yeah?
Okay,
so
yeah?
We.
B
Right
yeah,
it
can
be
point
to
point
pure
point-to-point
communications,
so
yeah
when
we
define
servers
inside
asic
api.
That's
why
I
was
suggesting
that
we
use
remotes
and
local
servers.
B
E
B
E
B
Real
time
so
yeah
these
things
need
to
be
also
considered
that
they
may
not
be
pure
brokers,
pure
routers.
There
may
be
something
else
involved
there
so,
and
this
is
something
that
we
should
consider,
because,
especially
financial
companies,
you
know
finance
companies
like
you
know,
banks
or
insurance
companies.
They
they
tend
to
use
a
lot
of
these
systems
so
yeah
and
it's
important.
E
D
B
So
yeah,
let's
put
that.
E
Is
there
this
is
a
little
self-serving.
I
apologize
for
that,
given
given
my
interest
in
the
nat
side,
but
nats
for
request.
Reply
is
sort
of
completely
dynamic
on
sort
of
the
reply
channel,
so
the
requester
basically
just
sends
the
reply.
Subject
that
the
service
responder
will
use
to
asynchronously.
Send
the
response
yes
are.
We
is
the
current
level
of
spec
sort
of
allowing
that
dynamicism
or
does
it
assume
a
statically
created
reply
channel.
B
So
so
far,
not
even
statically,
so
so
far
the
current
request
reply,
suggesting
is
that
we
actually
incorporate
these
things,
so
we
we
should
be
able
to
tell
that
the
channel
where
use
will
be
responding.
B
It's
on
whatever
header
of
the
message
or
is
specified
on
the
body
of
the
message,
which
is,
I
don't
think
it's
typical.
I
think
it's
usually
headers
so
so
yeah,
so
it
will
be
possible
to
do
it.
Like
the
reply,
the,
where
are
you
replying,
don't
know
it's
a
dynamic
channel
that
is
created
specifically
for
this
reply
and
once
the
replies
has
been
received,
probably
even
the
channel
is
destroyed
so
so
yeah.
B
D
E
Know
you
know
just
for
just
for
gnats
they're
sort
of
it
can
get
intricate,
but
there's
here's
my
reply
channel
and
it's
of
one
of
three
types.
I
expect
a
single
message
in
reply.
I
expect
end
messages
in
reply,
so
it's
like
a
reply.
Stream,
yes
or
or
even
I
have
a
sense
of
chunked
encoding,
so
they're
sort
of
like
here's.
E
My
reply
default
is
a
single
response,
just
sort
of
like
a
request
reply
like
a
http
case,
but
but
I
might
define
that
no,
it's
actually
here's
my
request
and
I
might
get
a
whole
stream
of
messages
in
response
over
some
period
of
time.
Yeah.
B
And
so
we
should
probably
go
for
the
common
for
what
they
have
in
common
with
across
different
messaging
systems
and
say,
for
instance,
the
reply
will
be
sent
to
this
channel
and
then
on
the
nats
binding
specify
if
it's
going
to
be
a
single
response
of
or
if
it's
going
to
be
as
a
stream
or
whatever
other
kind
of
responses
that
you
can
get
there
right
yeah,
but
only
for
nets.
B
So
we
keep
it
specific
for
nets
right
and-
and
the
core
specs
will
just
say
like
hey
respond.
Is
response
is
going
there
to
whatever
channel
that
we
may
or
may
not
know
in
defense,
and
that's
it
and
then
from
there
on
is
just
a
matter
of
kafka.
Supports
this.
I
mean
kafka
actually
now,
but
amqp
supports
that
that
kind
of
actually
activates
the
tunes
one
day.
They
all
support
these
things
nats
as
well,
but
probably
in
a
different
way
or
different
set
of
features.
E
B
E
I'm
sure
yeah
nats
is
not
probably
not
unique
there
and
then
is
there
a
point
of
view
on
whether
how
to
express,
maybe
in
a
in
a
in
an
async
api
interface?
Is
there
a
way
to
express?
Is
this
I'm
making
a
service
request
and
it
will
be
directed
to
basically
one
service
responder
one
service
responder
will
get
it
versus
more
of
a
scatter
gather
type
request
reply
scenario:
10
service
instances
could
get
it
and
I'll
send
responses
back
to
the
client.
B
E
Yeah
yeah
yeah,
I
apologize.
I
I
I
I
want
to
spend
some
more
time,
so
I
can
speak
intelligently.
I
know
you
guys
are
working
on
this
for
no.
B
B
B
B
Cool
folks,
so
I
think
that's
a
wrap.
We
have
another
meeting
in
two
weeks
same
time
and
yeah
don't
wait
for
don't
wait
for
the
meeting.
If
you
have
any
suggestions,
of
course,
let
me
check.
I
should
have
been
checking
the
chat
on
the
live
stream,
but
yeah.