►
From YouTube: Spec 3.0 Meeting
Description
A
A
A
B
Yeah
but
as
I
remember,
we
probably
should
do
discussion,
but
not
by
the
issue
or
something
like
that
yeah.
In
the
previous
meeting,
I
had
some
insight
that
probably
we
have
a
problem
inside
the
component
section
where
we
define
the
security
schemas,
because
as
the
definition
of
components
and
that
the
component
definition
means
that
it's
a
reasonable
parts
in
the
specification
there.
B
But
if
we
define
the
security,
we
exactly
first
need
to
define
some
security
schemas
inside
the
components
and
then
use
that
security
inside
the
server
security
or
in
the
operation
security.
By
not
the
reference
to
this
to
the
security
schema
by
you
know
the
dollar
ref,
but
by
exactly
by
the
name
of
the
key.
Yes,
so
yeah.
B
So
maybe
we
should
move
the
security
scheme
as
outside
the
components
and
it
will
have
the
same.
I
mean
the
power
like
the
channels
or
you
know
the
servers
just
the
same
level.
A
C
D
B
B
Into
the
room,
because
everything
I
mean-
maybe
it's
the
only
problem
with
with
me
with
my
thinking
and
that
everything
from
the
components
except
the
security
scammers,
we
you
know
referenced
by
the
dollar
refugees.
So
we
exactly
point
to
this
object
and
it's
exactly
the
same
reference
when
we
make
the
reference
the
referencing,
but
with
the
security
schema.
You
know
it's
it's
some
convention,
but
it's
exactly
the
copied
from
the
open
api.
E
A
However,
the
way
that
it
functions
is
that
these
security
schemas
must
be
defined
within
the
component
section
and
not
within
this
server.
Specifically,
that
means
that
you
are
referencing
it
regardless,
but
it's
it's
yeah,
exactly
it's
referenced
by
the
name,
and
then
we're
kind
of
mixing
between
reusability
and
where
you
actually
define
the
security
requirements
update
specifically
for
for
both
the
server,
but
this
application
or
wherever
the
context
is
yeah.
A
B
A
A
Yes,
okay,
perfect!
All
right!
F
What
about
we
just
leave
it
on
components
and
we
don't
add
anything
on
the
root
level,
but
we
change
the
referencing
mechanism
from
from
by
name
with
using
dollar
ref
so
from
the
server
definition
or
from
the
operation
definition.
We
just
double
rev
the
one
in
components.
C
B
C
B
B
You
know
the
definition
and
then
scopes
something
like
that
yeah,
so
so
yeah
yeah,
so
it
can
be
problem.
Of
course
we
can
still
have
this
component.
Yes,
for
me,
it
is
not
a
problem
at
all,
but
I
have
only
this
problem
that
you
know
that
we
say
the
component
is
reasonable,
but
the
security
schemas
works
in
different
way,
yeah.
So.
F
And,
and
also
like
what
does
it
mean
that
something
is
in
components
and
something
is
outside
the
component,
so
for
me,
for
instance,
the
way
I
see
it
and
the
proposal
that
I
that
I
did
for
the
public
subscribe
and
so
on,
which
is
fixing
much
much
more
stuff
than
just
a
couple
subscribe,
is
whatever
is
outside
components.
It's.
F
It
means
that
it's
going
to
be
used
is
happening.
It's
used
right
and
whatever
it's
in
components
is,
it
might
be
used
or
may
not
right.
It
may
be
used
or
may
not
like
it's
there
in
case
you
know
for
reusability
purposes,
but
it's
also,
you
might
want
to
throw
something
there
and
you
might
use
it
in
the
rest
of
the
document
or
might
not.
But
whatever
is
outside
components,
it's
like
no.
No.
This
is
used
for
sure
like
there's.
No
doubt
it's
always
used.
F
Here
are
a
few
of
the
security
mechanisms
you
might
you
may
or
may
not
use
them,
and,
and
the
ones
in
the
one
in
the
root
of
the
document
will
be
like
these
are
the
ones
that
I'm
using
so
that
actually
I'm
using
that's,
why
I
was
saying
like
maybe
we
should
be,
we
should
be
referring
by
using
them.
F
I
mean
it
will
be
like
guests
from
scanning
the
the
server's
object
and
scanning
the
operations
objects,
and
this
way
you
know
which
ones
are
being
used
and
which
ones
are
not
yeah,
because
otherwise,
if
we
move
them
to
the
root,
we
we
create
another
key
on
the
root
and
we
call
them
security
schemes.
F
C
F
You
know
another
reusable
part,
so
maybe
maybe
we
should
rethink
the
whole
the
whole.
You
know
security,
yeah
and
the
way
we
define
it.
We
don't
have
to
map
open
api
one-on-one
right.
B
C
F
We
will
have
to
be
enforcing
and
checking
the
rest
of
the
object
and
making
sure
that
this
security
mechanisms
are
being
actually
used
and
if,
if
one
of
them,
even
just
one
of
them,
is
not
being
used
or
referenced
somewhere,
then
it
should
throw
an
error,
because
this
is
not
the
place
for
unused
stuff
yeah.
Exactly.
B
B
F
Okay,
I'll
I'll
just
put
a
note
here,
title
magic
to
create
the
issue.
D
B
Yeah,
but
I
also
I
remember
that
in
the
open
api
they
starting
the
discussion
about
the
next
major
version.
Yes,
the
4.0
and,
as
I
remember
one
one
person
exactly
have
the
same
problem.
Yes
with
that,
so
maybe
I
don't
want
to
say
that
they
made
the
collaboration
or
something
like
that.
But
you
know
the
gives
the
information
that
we
want
also
to
fix
that
problem.
B
G
Say-
and
I
have
to
say,
I
don't
see:
what's
the
what's
the
problem
really,
like
I
mean
like
you,
can't
really
replace
current
way
of
linking
between
security
and
the
security
scheme,
you
can't
replace
it
with
ref
because
sometimes
you
add
the
scope
information.
So
how
do
you.
B
G
B
B
So
if
you
want
to
know
which
type
of
security
you
need
to,
you
know
the
to
create
in
your
application
or
you
know,
use
to
authorize
to
the
application.
You
should
exactly
see
the
component
sections
not
inside.
You
know
the
the
place
where
you
define
the
security
and
we
understand
or
no
no.
G
No,
no,
not
really
I
mean
I
can
like,
like
especially
in
off
right,
so
I
can
have
different
scopes
per.
G
B
Store
out
and
this
pastor
out,
the
name
is
exactly
reference
to
the
some
security
means
described
by
the
key
inside
the
component
security
schemas.
So
you
need
that
key
inside
the
component
security
schemas,
and
this
is
a
definition
for
the
security
yeah
and
yeah,
and
the
main
problem
is
that
the
components
say
it's
reasonable
parts,
but
the
component
security
schemas
takes.
You
know
the
part
in
the
specification
that
you
exactly
use
it,
but
you
don't
need
to
do
that
like
the
front
side,
that
the
the
channels
and
the
servers
yeah
is
use
it
yeah.
B
F
One
thing
like
maybe
I
mean
for
maybe
not
for
sure,
we'll
have
to
change
the
shape
of
this
object
right.
So
we
will.
We
could
probably
be
saying
something
like
security
requirement:
pet
store
off
extra
information
right,
pads,
read
pads,
you
know
what
I
mean,
so
that's
how
you
will
do
it
and
then,
instead
of
pester
off
as
a
string,
you
use
a
dollar
rev
to
the
pester
of
mechanism.
F
G
Yeah,
just
just
changes
driven
by
aesthetics
or
like
some
tooling
issue,
because,
like
I
mean
I
want
do,
we
want
just
to
be
consistent
or
like
so
we
I
mean:
do
you
see
a
problem
that
we
sometimes
ref
by
just
a
name
instead
of
using
dollar
ref?
Because
we
do
it
like,
with
with
security,
not
security,
with
servers
on
the
on
a
channel
right
and.
G
C
E
H
E
B
Okay,
but
but
one
thing
that
we
forgot
when
we
defined
the
servers
on
the
channel
side,
that
if
you
make
the
reference,
not
all
the
tooling,
I
think
the
the
the
most
known
make
the
reference
by
the
reference
in
the
code.
So
it
means
that
after
the
referencing,
you
have
exactly
the
json.
Yes,
that
you
can,
for
example,
read
in
the
javascript
and
then,
if
you
compare
the
object
defined
in
some
components
and
then
compare
the
object
that
it's
exactly
the
reference
in
some
places,
it's
exactly
the
same
reference.
B
Yes,
exactly
the
same
reference
and
you
know
in
the
json,
so
we
probably
make
the
wrong
decision
when
we
define
the
servers,
because
we
on
the
touring
site
only
can
you
know
they
should
check
the
the
reference
in
the
code?
Not
the
you
know
the
reference
by
the
name.
Maybe
you
don't
yeah?
Probably
you
don't
understand.
B
I
mean
you
understand
or
not,
because
I
can
say
this
in
the
other
form,
if
you're.
G
B
How
to
describe
this?
You
have
some
message:
yeah
in
operation,
you
exactly
made
the
reference
in
operation
and
this
method
is
described
in
the
component
messages,
but
then,
after
the
referencing
in
the
javascript
code,
after
the
parsing,
you
you
know
have
some
json
and
then,
if
you
make
exactly
the
comparison,
yes
of
your
object,
something
like
the
essence
api
that
some
channel
yeah
that
this
operation
published
that
message
compared
to
this
same
object
inside
the
components
messages
you
will
have
the
true.
B
So
this
is
the
same
references
yeah
and
by
this
you
can
check
if
the
given
server.
Sorry,
if
the
given
messages
is
exactly
used
by
the
reference.
Yes,
so
if
we
now,
you
know
jump
to
the
server
definition
inside
the
channels.
We
can
also
do
this
not
by
the
string
by
the
exactly
by
the
reference,
but
there
is
also
the
problem
that
the
people
will
be
able
to
define.
You
know
the
servers
outside
the
server's
object
like
in
the
open
api
that
you
can
define
the
additional
servers
for
the
given
operation.
G
B
C
F
Can
still,
you
can
still
have
like
what
we
have
in
in
operation
in
the
operation?
We
have
a
list
of
servers
by
by
name
not
using
dollar
rest.
You
can
still
iterate
on
this
array
and
inject
the
reference,
the
references
to
to
the
servers
right
and
then
you
can
compare
by
reference
in
javascript
or
another
language.
So
you
can
thing
is
that
this?
The
referencing
mechanism
needs
to
be
built
by
you,
or
it
will
be
provided
by
an
existing
library
like
in
the
case
of
dolorev.
B
F
F
Who
cares
right,
but
I
will
even
argue
that
a
that's
a
bigger
problem,
if
at
all,
if
it's
a
problem
is
and-
and
that
is
stopping
me
from
proposing
that
we
move
away
from
dollar
rares
in
most
of
the
cases-
is
the
is
the
code
editor
support
right.
So
the
code
editor
usually
now
all
of
the
code
editors
support,
json
schema
or
they
have
plugins
to
support
using
schema,
and
this
dollar
ref
mechanism
is
something
that
json
schema
is
defining.
F
F
If
we
reference
by
name,
we
lose
that
right.
So
to
me,
that's
a
bigger
problem,
still
not
a
problem,
but
it's
a
bigger
problem.
If
you
will
right
more
than
just
whatever
implementation
detail
right
that
we
should
be
supporting
or
something
like
I
mean,
I
don't
think
it's
a
problem
and
with
security.
F
What
I
see
here
is:
it
might
be
just
an
aesthetic
change,
as
lucas
was
saying
like.
F
We,
I
don't
know
we
should
be
clear
on
just
at
least
in
my
opinion,
like
the
meanings
that
I
was
saying,
that
we
should
be
clear
on
what
having
something
components
means
and
what
having
something
outside
components
means
and
so
and
leaving
it
clear
like
there's.
No
doubt
there's
no
room
for
interpretation
but
other
than
that
like
having
it
as
a
key
or
as
a
reference
as
a
dollar
ref,
or
something
like
that.
F
A
And
when-
and
this
depends
on
how
specifically
you
design
or
edit
your
async
api
documents,
because
if
you
use
a
tool
for
it,
then
it
can
abstract
away
from
that
problem.
But
if
you
manually
edit
those
documents,
then
you
have
to
know
exactly
where
those
names
are
referenced
to,
because
it's
implicit
that
you
know
it
based
on
whatever
the
spec
says.
It
is.
F
I
think
I'm
bringing
a
bigger
problem
now
that
I'm
thinking
about
like
we're,
assuming
that
these
keys
are
present
in
components
right
and
we're,
assuming
that
this
server
reference
this
server.
Sorry,
this
security
requirement
is
inside
the
server,
for
instance,
in
the
same
document.
But
what
if
the
server
definition
is
in
another
file
right,
you
need.
F
F
You
will
be
referencing
something
that
needs
to
be
on
the
component
on
the
place
where
this
server
is
going
to
be
used.
So
you
don't.
You
cannot
just
reference
the
server
and
it
will
work
right
because
you
will
need
to
reference
the
server
and
add
the
security
requirement
to
the
components
for
it
to
work.
F
So
that
might
be
any
a
bigger
inconsistency
I
would
say
like
in
in
terms
of
reusability
like
when
we
want
to
if
we
want
to
dissect
or
detect
the
whole
spec
and
make
it
reusable
across
many
files,
or
even
a
central
repository
for
the
whole
company,
where
all
the
servers
are
defined,
which
is
very
likely
to
be
then
in
europe.
In
your
system,
api
file,
you
want
to
reference
that
remote
url,
where
the
server
is
defined
and
it's
saying
I'm
using
the
pet
store
of
security
requirement.
F
But
the
pets
are
of
security
requirements,
not
in
your
components,
in
your
components
section,
so
you
will
have
to
go
there
and
add
it
again
in
each
of
them.
Instead
of
being
able
to
add
it
in
in
alongside
the
central
definition
in
your
central
repository.
B
Yeah
we
have
the
same
problem
also
if,
with
the
servers
and
the
channels,
and
as
I
remember,
we
have
also
the
issue
for
that
yeah-
that
if
you
have
in
the
component,
you
define
some
channel
in
the
the
component
channels
and
if
you've
write
the
servers
by
the
names.
You
must
also
remember
that
you
need
to
define
the
servers
here,
because
then
I
mean,
of
course,
if
you
reuse
that
channel
here
yeah
but
yeah,
it's
a
problem
yeah.
That
is.
F
B
B
G
So
so
I
understand
like
like,
for
example,
the
the
bigger
issue
that
frank
described,
that's
actually
very
valid,
like
we
give
you
flexibility,
you
can
reuse,
but
not
security,
but
in
case
of
servers
on
a
channel
you,
like
I
mean
why
would
you
reference
something
outside
the
document
like
you
should
have
these
servers
like
it's
for
your
application
servers
of
your
application,
so
you
should
have
them.
F
In
the
in
this
case
is
the
other
way
around
yeah
like
you're,
not
you
don't
have
something
external
that
is
referencing,
something
in
your
document.
You
have
something
in
your
document
that
will
be
referenced
in
something
external
and
that's,
in
my
opinion,
that's
fine.
You
should
just
go
to
the
server
section
and
and
add
it
and
add
them
right.
So
there's
different
cases
yeah.
So
it's
the
same
thing,
but
in
different
directions
right.
So
the
reference
is
happening
in
different
direction,
but.
B
F
You
define
this
example:
yeah
yeah
yeah.
But
that's
that's
the
point,
so
you
can
have
a
central
repository
of
all
the
channels
and
all
the
servers
and
and
all
the
reusable
pieces
right
and
it
will
work
because
they're
all
in
the
same
document
right.
So
these
references
to
to
the
servers
from
the
channels
they
will
be
mad.
They
will
be
found
because
they're
in
some
in
the
same
document
right
but
well
actually.
F
Just
using
dollar
ref
is
not
going
to
work,
so
so
yeah
yeah
still
a
problem.
I
think.
B
F
B
F
Because
when
you
don't,
when
you
use
dollar
ref,
you're
referencing
the
channel
with
all
the
with
the
list
of
I
mean
unless
we
use
dollar
ref
inside
on
the
server's
property
inside
the
operation
right
which,
by
the
way
we
should
be
talking
about
operation
other
channels
but
or
maybe
not.
Maybe.
F
F
F
F
This
channel
you're
gonna
get
references,
not
dollar
rep,
but
references
to
servers
that
are
not
in
your
document
and
they
should
be,
and
then
you
you'll
have
to
go
and
redefine
it
again
in
your
document
and
another
document,
you'll
have
to
redefine
it
again
in
another
document.
So
that's
a
problem.
F
F
C
B
The
servers
that
are
defined
in
the
channel
and
as
the
servers
that
it's
only
you
know
available
on
the
given
channel.
B
B
The
given
channel
and
sorry
the
the
one
server
defined
in
the
server
in
the
channel
servers
has,
you
know
only
the
one
channel
in
this
way
and
okay,
because
at
the
moment
you
have
two
options:
yeah,
you
have
the
options
that
if
you
define
the
servers
on
the
root
and
the
channels-
and
you
mean
that
all
channels-
and
you
know
sorry
for
for
the
given
server-
you
can
use
the
old
channels.
B
D
B
B
F
F
B
B
So
it
means
that
the
servers
it's
really
hard
to
to
explain
really
really.
I
know
that.
B
Yeah,
I
know
the
open
api
has
probably
very
similar
similar
mechanism
in
the
operations,
because
you
can
also
define
the
servers
for
the
particular
operation.
Yes
yeah,
and
by
this
you
exactly
write
the
definition
of
the
server
not
by
the
key
yeah.
So
at
all,
you
don't
need
to
have
the
servers
yes
defined
by
that
in
the
servers
sections,
but
only
in
the
operation.
Yeah,
yeah
and.
B
C
E
E
H
B
F
H
F
A
A
G
Magic
thank
you
and
before
magic
continues,
like
jonas,
dear
moderator,
would
you
like
me,
because
there
are
some
comments
in
the
in
youtube
yeah
for.
C
A
G
Like
do
we
want
to
read
it
because
it's
regarding
the
ranting
we
had
and
of
course,
if
I
read
it,
then
we
will
probably
continue
but
yeah.
C
G
Okay,
sorry
sergio
wrote
another
comment
by
the
way:
greetings
sergio.
I
remember
some
discussion,
jonas
and
I
had
on
this,
describing
how
bundling
and
re
referencing
should
work
and
an
alternative
to
this
pack
was
to
write
those
rules
down
in
the
in
the
parser
api.
G
A
I
think
we
actually
have
an
issue
for
it,
but
it's
nothing
that
has
been
specifically
defined,
define
how
to
handle
dereferencing,
because.
A
But
if
you
start
to
also
allow,
for
example,
that
we
already
do
with
the
servers
and
the
names
specifically
that
could
probably
be
discussed
within
this
issue
as
well
yeah
but
yeah.
I
think
it's
the
he
is
referring
to.
If
you're
not
mistaken,.
B
B
But
I
only
thinking
a
lot
if
we
short
arrow
in
the
next
version
to
define
the
array
of
external
documentation
yeah
and
I
will
be
faster
than
you.
I
don't
have
any
production
use
case
for
that,
but
I
only
you
know
then
wonder
how
the
development
of
the
spec
should
look
like.
Should
we
look
like
this
in
the
next
month
after
the
release
of
the
tiered
version,
because
of
course,
on
the
spect
site,
it
won't
be.
B
The
problem
to
you
know
to
allow
define
the
external
documentation
of
the
single
object
and
also
the
of
the
ri,
but
from
the
tooling
site.
It
won't
be
the
problem
because
you
know,
because
in
the
parser.js
by
the
intent
we
change
the
returning
type
of
of
the
methods
yeah.
So
people
will
have
the
problem
if
the
given
the
given
data
is
a
single
object
or
the
array
of
the
object,
yes
of
the
given
type.
B
F
Seems
to
make
sense
to
me,
but
yeah,
like
especially
the
contact
like.
I
can
understand
that
some
companies
want
to
have
multiple
contact
channels
yeah.
It
will
make
sense
like,
for
instance,
email
phone
twitter
if
we
end
up
having
also
twitter
or
something
like
that,
but
I
don't
know,
but
maybe
this
will
be
fields
in
the
contact
object
instead
of
a
collection.
So,
for
instance,
we
have
name
url
email.
So,
instead
of
doing
this,
we
can
just
add
twitter
right.
B
Yeah
yeah
yeah,
but
the
difference
sorry
front
is
the
difference
because
in
this
proposal
I
want
to
add
several.
You
know
the
person.
Yes,
of
course
he
usually
add
the
information
or
the
contact
to
the
api
support.
Yes,.
F
G
F
B
B
And
for
that
we
need
to
consider
on
the
next
major
version
yeah,
because,
as
I
said,
then
you
know
if,
if
someone
will
run
to
the
the
external
documentation,
as
the
ri
we
will
have,
the
problem
is
from
the
turning
side,
because
we
need
to
change
them.
You
know
the
how
to
call
that
not
the
return,
the
returning
time
by
the
not
the
definition
of
the
method,
yeah.
B
A
H
A
And
that
would
be
a
terrible
user
experience
as
well
exactly.
F
Everything
you
never
know,
you
never
know
the
scripture
like
yeah.
Let's
have
a
description
for
spanish
and
another
for
emails.
G
Actually,
more
more
useful
would
be
something
that
already
damn
it.
I
forgot
the
name,
this
tooling
bump
bamba's
age,
no
bump
it's
this
service
solution
for
that
lets.
You
document
open
api
and
asking
api
like
basically
lets
you
document
api
by
just
providing
us
in
dba
and
open
api
and,
as
a
like
from
my
background,
as
a
stack
writer.
G
I
remember
that,
like
like
reference,
docs
is
not
enough
and
you
always
have
to
add
some
additional
information
like
some
introduction
to
the
api,
some
some
more
generic
documents
and
how
they
do
it
here,
and
I
bet
others
do
it
as
well,
and
it's
actually
there's
an
extension.
Some
time
ago
I
proposed
but
yeah,
there
were
many
other
things
but
yeah.
G
So
basically,
what
I'm
trying
to
say
is
that,
instead
of
having
an
array
on
external
docs,
it's
actually
useful
to
have
docs
or
docs
topic,
whatever
new
collection,
where
you
can
actually
reference
or
write
additional
documents
for
the
given
api.
So
you
don't
reference
out,
so
you
don't
point
to
an
external
url,
but
you
actually
put
documentation
inside
the
inside
the
async
api
or
open
api,
and
they
do
it
by
reference
they
just
by
by
extensions,
so
they
have
for
now
they're
just
extending
spec
with
the
x
dash.
G
G
I
think
they
also
support
some
custom
extension,
so
yeah
just
rounding
about
the
external,
docs
and
usefulness
of
collection,
more
useful,
probably
a
collection,
probably.
F
A
good
use
case
for
for
the
extensions
catalog
right
like
to
propose
something
there
iterate
there
and
then
at
some
point
we
might
want
or
not
to
integrate
it
into
the
core
spec.
F
G
Tomorrow
or
now,
that's
why,
in
the
end,
I
put
it
in
the
extensions
because
it's
not
critical,
even
guys
from
bump,
don't
push
for
it.
So.
H
E
A
G
Maybe
next
time
it's
like
a
suggestion,
maybe
next
time
it's
it's
good
to
yeah,
ask
ask
others
like
like
what
topic
they
came
for
for
the
meeting,
because,
like
looking
on
the
audience,
I'm
I'm
pretty
sure
michael
came
exactly
for
the
topic
that
we
did.
C
Showed
up
because
I
haven't
been
there
been
here
for
a
while
and
I'm
just
trying
to
catch
up
again,
so
I
didn't
even
pay
much
attention
to
the
agenda.
To
be
honest,
oh.
C
Yeah
yeah
yeah
yeah.
That's
right!
That's
still
something
we're
very
interested
in,
but
yeah
I'll
start
showing
up
again.
I
just
been
very
busy.
G
G
F
It
would
be
good
to
to
survey
to
ask
people
in
the
beginning
of
the
call
and
say
like
what
ease
were
you
joining
for
and
then,
if
and
then
we
can
follow
the
order
of
the
most
interesting
issue
and
then
we
can
change
the
the
order
of
the
agenda.
If
that's
fine,
maybe
we
cannot
change
it
because
some
people
have
to
leave
or
something
like
that.
So
it
makes
sense.
C
F
I
mean
we,
we
could
have
been
speaking
about
the
security
object.
You
think
at
the
whole
the
whole
meeting
we
could
have
been
speaking
about
it.
The
whole
meeting
really.