►
From YouTube: GraphQL over HTTP Working Group - 2022-06-27
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
C
Yeah
yvonne.
C
Was
I
believe,
kind
of
a
de
facto,
but
there
was
a
point
in
which
he
stepped
back
and
asked
for
some
help
and
semi
transferred
that
to
me.
But
everything
has
been
very
loose
in
this
working
group.
C
Although
why
don't
I
let
you
lead
this
meeting,
because
you
had
thoughts
on
what
we
should
discuss
today.
A
Yeah,
okay
sounds
good.
Well,
we
all
know
each
other,
so
we
can
skip
over.
The
normal
stuff
would
be
great
to
take
some
notes
if
any
anyone's
available
to
do
so.
I
think
my
main
motivation
for
this
and
I'm
sorry
that
I
haven't
actually
added
an
item
to
the
agenda
for
it.
Well,
there's
two
right:
one
is
to
get
any
further
feedback
on
the
pull
requests
that
I've
raised,
but,
more
importantly,
it's
to
kind
of
make
a
plan.
A
I
think
it
would
be
great
to
aim
to
get
the
graphql
over
http
spec
included
as
part
of
the
next
release
of
the
graphql
spec
like
tied
into
the
same
release
cycle,
which
may
mean
that
we
need
to
you
know,
get
some
work
done
quite
quickly,
but
I
think
we're
actually
pretty
close.
A
There
are,
however,
a
few
things
that
I
wonder
whether
we
do
or
do
not
need
to
cover
so
things
such
as
authentication
and
other
topics
as
well.
I
guess
there's
quite
a
few
that
could
come
up.
Does
anyone
have
anything
else
that
they
would
like
to
talk
about
today?.
C
No,
I
my
real
motivation
at
this
point
is
to
bring
life
back
into
the
into
this
spec
and,
to
you
know,
see
what
it
takes
to
get
to
an
official
form,
excellent.
B
Yeah,
that's
that's
mostly
what
I
thought
too.
You
seem
to
have
a
plan
for
and
a
date
for
when
we
could
actually
go
official
with
this
one
because
yeah,
I
don't
see
many
outstanding
issues,
so
that
would
be
great.
A
Okay,
cool
well,
let's,
let's
dig
into
so
one
of
the
main
things
in
my
pull
request
is
obviously
the
the
watershed,
which
is
a
new
thing.
I
think
everyone's
agreed
that
it's
it's
a
reasonable
thing
to
add.
There
is
some
pushback
on
whether
it
should
be.
You
know,
default
default
enabled
or
default,
like
servers,
should
support
it
after
the
watershed.
But
do
clients
have
to
send
it
or
can
they
just
keep
sending
the
old
traditional
json
and
accepting
json?
A
So
I
think,
there's
a
there's
a
little
bit
of
a
question
over
that.
I'm
happy
with
the
the
text.
That's
currently
written.
Also
david
raised
some
compelling
notes
about
the
security
consequences.
A
Things
like
cross,
cross,
site,
request,
forgery
and
other
such
things.
I
I
would
love
to
just
basically
say
those
are
outside
of
the
scope
of
this
spec,
because
those
kind
of
things
are
well
documented
elsewhere.
You
know,
you've
got
and
also
it's
dependent
on
how
people
do
things
right,
so
if
they
are
using
jwts
versus
versus,
if
they're
using
sessions
versus
some
other
solution
and
so
on
and
so
forth.
A
However,
it
probably
would
make
sense,
even
if
we
don't
have
any
normative
specifications
around
that
to
have
at
least
some
non-normative
notes
saying
you
know
if
you
are
enabling
this
over
get,
then
you
must
do
this
than
the
other.
If
you
are
supporting
these
particular
media
types,
then
you
need
to
be
aware
of
cross-site
request
forgery,
and
you
know
here's
where
you
go
to
look
for
information
on
that.
Maybe
what
is
your
take
on
that?
A
Do
you
think
that's
something
that
we
should
actively
specify
that
we
should
comment
on
in
a
note
or
that
we
should
just
ignore
entirely.
C
C
You
would
do
that,
whether
you're
serving
graphql
or
anything
else-
and
we
don't
mention
all
sorts
of
other
things
with
respect
to
http.
Why
that.
A
This
spec
acts
on
top
of
standard
http,
best
practices
which
relate
to
you
know:
security
like
cross-site,
request,
forgery,
etc,
and
you
should
bring
your
knowledge
of
those
things
when
you
apply
this
spec,
because
I
I
don't
think
as
as
you
say,
gabriel,
I
really
don't
think
that
we
should
be
specifying
deeply
how
to
do
security
it
just
doesn't.
A
It
does
seem
out
of
scope,
but
equally,
if
we
don't
comment
on
it
and
then
someone
just
implements
the
spec
verbatim
and
is
like.
Oh
no,
I've
got
these
cross-site
requests.
Forgery,
that's
a
bug
in
you
know
the
graphql
over
http
spec.
I
also
think
that
wouldn't
be
a
good
look
for
graphql,
so
I
do
feel.
C
I
honestly
just
I
don't
think
that
is
a
case
that
could
happen,
and
specifically
I
mean
I
don't
think
if
somebody
had
a
cross
any
security
issue
really
that
they
could
point
to
this
spec
and
say
see.
C
This
is
a
problem
with
the
spec
if
they
built
something
exactly
to
this
spec,
given
that
this
is
clearly
and
it's
titled
over
http,
if
they
ignored
security,
because
it
wasn't
mentioned
in
this
spec
if
they,
if
they
ignored
cookies,
because
we
didn't
mention
in
the
spec,
it's
the
same
thing,
it's
not
in
the
scope,
and
I
think
it's.
A
C
I
am
in
favor
of
putting
a
non-normative
note
that
says
you
know
something
to
the
effect
of
following
http
best
practices
or
something
like
that.
B
Yeah,
I
also
I
also
like
the
point
suggesting
that
they
made
about
having
csrf
protection
enforced
by
just
forcing
the
client
to
send
content
type.
B
Having
that
as
it
should,
it
doesn't
really
help
interoperability
to
let
clients
omit
this
header.
I
think
that's
that's
the
thing
where
yeah
you
will
get
the
the
error
once
that
you
have
to
send
the
content
type
and
then
you
just
do
it
and
then
it's
it
works
forever.
So.
B
That's
what
david
suggested
yeah,
I
think
I
think
that's
reasonable.
A
I'm
I'm
uncomfortable
with
that.
I
think
it
should
be
left
in
the
hands
of
the
server
developers.
We
can
recommend
against
it,
which
we
do
with
the
should.
I
mean
that's
the
same
as
like
you
know
it's
the
same
as
recommending
not
to
do
it
or
to
do
it
whatever,
but
if
we
strictly
rule
that
that
said,
that
said,
if
we,
if
we
forbid
it
currently,
we
can
always
lift
that
forbiddenness
later.
I
think.
A
Yeah,
I'm
just
thinking
in
terms
of
there
are
a
lot
of
graphql
servers
out
there
already
and
part
of
the
intent
of
this
release
is
to
you
know,
keep
as
many
of
them
as
possible,
spec
compliant,
and
if
that
means
that
they
have
special
code
in
there.
That
says.
Oh,
if
there's
not
a
content
type,
then
we
know
you
know
it's
probably
jason
or
like
we
look
at
the
first
character
and
if
it's
a
curly
brace,
we
go.
A
A
If
they
continue
to
do
that,
then
officially,
we
would
be
saying
that
their
server
is
not
over
http
compliant,
which
I
don't
think
is
really
true.
The
the
aim
for
the
graphql
over
http
spec
is
to
say
these
are
the
things
that
the
server
must
do
so
that
the
client
can
talk
to
it,
and
likewise
these
are
the
things
that
the
client
must
do
so
that
it
will
work
with
any
server.
C
One
note
as
well:
I
don't
know
if
this
should
still
be
considered
our
our
goal,
but
earlier
this
group
had
the
goal
not
to
create
a
first
version
of
this
spec
to
be
strict
and
forceful,
but
to
create
a
loose
specs
so
that
it
existing
implementations
could
feel
comfortable
with
what
we
have
and
the
knowledge
that
we
are
going
to
become
more
strict
in
the
future.
C
And
I
think
maybe
that
is
an
area
where
we
could
allow
that.
We
could
say
in
the
watershed
event,
that
we
will
start
becoming
more
strict
in
this
area.
B
I
think
the
specific
thing
it's
not
something
that
would
prevent
servers
from
working,
but
it's
also
something
where,
if
a
server
implementation
decides
to
disregard
that
part
of
the
spec,
that
also
doesn't
prevent
it
from
working.
B
B
I
think
it's
generally
generally
a
good
idea
to
explain
statements
made
on
the
spec.
Of
course
it's
I
agree
because
I
mean
we
put
a
lot
of
thought
into
if
a
specific
sentence
should
say
should
or
must,
but
then,
when
you
read
it,
I
think
an
explanation
really
helps.
You
understand
why
it's
the
case
and
why
it's
important
for
you
to
follow
us
back
in
that
case.
A
B
C
And-
and
I
think
that
should
be
a
good
practice
for
any
time,
we
have
a
should.
A
Okay,
great,
so,
let's
assume
that
we've
made
a
few
little
changes
based
on
this
and
we
we
merged
this
specification,
pull
request.
What
do
you
see
as
any
outstanding
actions?
I
think
we
might
need
to
put
a
couple
of
notes
in
there
based
on
david's
feedback
other
than
that
is
there?
Is
there
much
else?
What
do
we
need
to
do
before?
We
present
this
to
the
working
group
and
say
here's
our
our
first
draft.
A
C
Go
ahead,
I
was,
I
was
saying
that
the
only
reason
is
that
when
we
originally
spelled
out
those
stages,
our
goal
was
to
move
quickly
and
we
just
didn't,
and
so
I
I
think,
if
we're
going
to
move
forward,
perhaps
we
should
define
what
it
takes
to
become
draft
stage
or
even
further,
so
that-
and
maybe
that
doesn't
happen
until
the
work,
the
graphql
working
group
meeting,
so
that
we
could
be
clear
on
what
they
want
but
yeah.
C
I
I
think
it's
it's
just
clear
now
that
we
need
to
know
what
what
a
solid
first
release
of
this
looks
like
or
or
requires.
A
Yeah,
that's.
That
seems
reasonable.
I
think,
as
you
as
you've
hinted
at
it
might
be
a
case
of
it
is
preliminary
until
we
present
it
to
the
working
group,
at
which
point
we
raise
it
to
to
draft
status,
and
I
think
that
that
should
probably
be
done
like
our
job
in
this
sub-working
group
right
is
to
figure
out
what
the
solution
to
this
should
probably
look
like.
It
is
not
to
actually
put
this
final
rubber
stamp
on
it.
A
The
final
rubber
stamp
comes
down
to
the
main
working
group,
we're
just
a
subcommittee
effectively,
so
I
think
that
should
also
potentially
be
true
for
the
for,
like
the
draft
status
and
things
like
that
as
well
so
yeah,
I
suggest
we
get
it
in
as
good
a
shape
as
we
feel
that
we
can,
and
then
we
present
it
to
the
working
group
with
the
aim
of
people
at
the
working
group
reading
it
and
by
the
next
working
group
deciding
that
we
can
advance
it
or
that
we
can't
advance
it,
etc.
C
C
A
Okay,
great
well,
I
will
take
the
initiative
on
on
doing
a
few
minor
edits
to
this.
I
think
we're
due
to
merge
it
in
like
four
days
anyway,
so
I
might
just
let
it
go
ahead
with
the
merge
and
then
well.
I
might
do
a
few
minor
edits
that
I
don't
think
will
concretely
change
things.
You
know
adding
normal
non-normative
notes
and
stuff
like
that,
get
it
merged,
and
then
I
think
either
me
or
david
raise
a
few
improvements
with
regard
to
like
some
simple
comments
like
we
agreed
just
now.
A
I
don't
think
it
needs
to
go
into
great
detail
on
security
and
not
even
necessarily
even
mention
topics
like
cross
site,
request
forgery,
because
when
you
start,
when
you
start
listing
those
things,
there's
all
the
things
that
you
haven't
listed
right
so
think
more
in
terms
of
like
there
are
security
repercussions
of
doing
that
they
are
standard,
http
security
repercussions.
A
You
should
make
sure
you're
familiar
with
those
kind
of
thing.
That
kind
of
note
there
is
another
big
question
which
is
one
of
our
aims
with
this
was
to
build
a
structure
for
the
specification
to
help
us
as
we
go
forwards
right
at
some
point,
we're
going
to
be
adding
potentially
web
sockets,
or
that
will
be
a
side
one
also
same
for
service
and
events.
Maybe
that's
a
chapter
a
section
sorry
or
maybe
it
is
like
an
additional
spec.
A
Not
it's
not
immediately
clear
to
me
what
those
things
are,
but
one
of
the
comments
that
came
out
of
this
rewrite
is:
we've
talked
about
the
request
and
the
response,
but
should
we
instead
have
been
talking
about
the
client
and
the
server.
C
I
think
there's
room
for
both
in,
in
both
cases
the
client
and
server
each
have
roles
for
a
request,
client,
making
the
request
the
server
receiving
the
request
and
and
the
inverse
for
the
response.
The
server
has
to
send
the
response,
but
the
client
has
to
read
it.
A
Yeah
I
started
rewriting
it
in
in
terms
of
client
and
server
and
honestly
I
just
started
having
the
exact
same
problems
the
other
way
around,
just
as
you've
suggested
it
neither
way
wins
yeah,
so
yeah.
B
I
didn't
didn't
find
any
ambiguity
with
with
regards
to
having
those
two
terms,
sometimes
intermixed
or
used
in
different
places.
So
while
reading
the
spec,
I
was
never
confused
by
that.
So.
A
For
me,
yeah,
that's
good,
and-
and
you
know
I
I
do
try
and
avoid
ambiguity
where
I
can.
My
issue
is
more
like
someone
might
come
on
and
they
want
to
implement
the
client.
So
therefore,
maybe
they
should
only
need
to
read
the
client
section
or
the
server
sections
there
for
additional
information
kind
of
thing
which
may
be
beneficial,
but
also,
if
we're
talking
in
terms
of
like
request
and
response.
A
What
does
that
mean
when
it
comes
to
subscriptions
or
you
know,
live
queries
or
things
like
that
in
future?
What
does
it
mean
for
stream
and
defer
stream
and
defer?
Because
it's
the
response
is
now
a
stream
right,
multi?
Well,
seven
events,
I
guess,
is
quite
common
for
it
or
there's
a
there's,
a
bunch
of
different
approaches
you
can
use,
I
suppose,
is
request
and
response
the
right
shape
to
be
ready
for
those
future
things.
A
And
we're
changing
it
to
client
and
server
fix
that,
because
I
mean
to
me
it
feels
like
subscriptions
at
least
like
websockets
server
center
events.
Sorry
not
subscriptions
to
be
clear,
websockets
and
server
cent
events
they
feel
like
they
should
be
separate
sections
like
full
top
level
sections,
because
they're
very
different
right,
maybe
even
separate
specifications.
A
We're
talking
here
about
the
traditional
http
request
response
cycle.
Websockets
is
very
clearly
something
different
from
that
server
sent
events
is
actually
much
more
similar
to
a
request
response
shape,
but,
like
figuring
out
what
we
intend
to
do
when
we
get
there
should
influence
how
we
structure
the
spec.
Now
I
think,
but
it's
not
separating.
B
A
I
mean
the
payload
for
a
websocket
connection.
For
example,
it's
like
the
even
the
handshake
for
a
websocket
connection
is
quite
different,
so
I
don't
know
maybe
you're
right,
maybe
you're
right,
because
we
do
talk
about
it
in
quite
abstract
ways.
A
I
mean
we
don't
we
don't
give
much
in
the
way
of
examples
with
like
http
headers
in
place.
Do
we
like
we
hint
at
some,
obviously
content
type
and
accept,
but
we
don't
give
full
request
examples
so
yeah,
maybe
maybe
these
would
work.
C
In
the
same
way
that
I
think
of
code,
if
I'm,
if
I'm
writing
a
feature
for
say
an
mvp
or
v1
of
a
product-
and
I
know
that
future
versions
are
going
to
contain
certain
things-
the
only
thing
I'm
concerned
with
right
now
is
I'm
not
going
to
want
to
have
breaking
changes
at
the
time
of
that
new
feature.
C
So
if,
if
I'm
thinking
of
that,
with
respect
to
this
spec,
I'm
going
to
think
I
don't
want
to
force
a
server
implementation
or
client,
I
guess
either
one
to
have
to
go
back
and
re-implement
things
to
be
compliant
once
our
spec
starts
talking
about
websockets
or
server
sent
events,
even
though
they're
not
implementing
them.
So
as
long
as
we
make
it
clear
that
the
things
mentioned
in
this
spec
do
not
relate
to
those
things,
but
when
we
do
add
those
things
to
the
spec,
nothing
that's
in
here
so
far
will
change.
A
C
A
So
maintaining
the
current
structure,
the
maintaining
the
current
specification
wording
like
in
terms
of
musks
and
shirts,
but
also
keeping
them
in
the
same
sections
where
possible
so
that
it
doesn't
really
affect
people
that
aren't
implementing
websockets.
C
A
I
think
we
all
agree
on
that
point.
We
certainly
shouldn't
break
any
existing
clients
when
we
introduce
websockets
as
an
optional
feature,
server
center
events
as
an
optional
feature,
and
I.
C
As
long
as
we're
not
going
to
require
those
without
those
things
being
implemented,
then
we're
fine,
but
if
there
is
anything
that
must
that
must
change
in
this
spec
just
to
mention
those
things,
then
we
should
make
sure
we
do
that
now,
rather
than
later.
A
Yeah,
that's
a
good
point
and
I
agree.
The
the
main
reason
that
I
bring
this
up
is
the
the
road
map
document
that
we
created
all
those
years
ago
said
explicitly
in
it
that
one
of
the
aims
of
version
one
spec
was
in
layout
and
structure
version.
One
should
lay
a
foundation
for
future
development
and
standardization.
A
The
spec
in
the
right
structure
now
I'm
okay
to
actually
just
sidestep
that
and
say:
well,
we
think
it's
in
you
know
a
good
structure,
but
if
it
turns
out
when
we
write
the
websocket
stuff
that
we
have
to
restructure
it,
then
so
be
it
so
long
as
the
rules
themselves.
Don't
change
you
know
so
that
someone
that's
already
compliant
remains
compliant,
I'm
happy
with
that
if
need
be,
but
if
we
can
guess
that
what
the
structure
should
be
later
and
then
put
it
into
that
structure,
that
would
be
preferable.
C
C
Then,
if
we
can
imagine
adding
something
like
websockets
or
server
sent
events
as
as
you
said
earlier,
as
new
sections,
imagine
we
added
those
today
if
there
were
new
sections,
if
they
were
included
in
this
dock
and
not
in
a
separate
spec,
how
would
we
include
those?
C
Because
if
we
were
to
include
those
chances,
are
there's
other
things
that
will
be
included
in
the
same
way
and
if
we
can
imagine
that
and
structure
what
we
do
have
in
the
same
way,
for
example,
if
if
we
wrote
it
like
this
and
then
added
this
new
section,
it
might
look
shoehorned
in
oh
yeah.
Now
we
have
this
other
section.
C
Well,
maybe
we
should
have
added
a
heading
in
the
beginning
of
this
thing,
knowing
that
there's
going
to
be
another
heading
of
equal
weight
down
the
line,
and
if
we
just
do
that,
then
I
think
we
covered
that
yeah.
B
Yeah,
I
think
the
current
headings
might
not
not
work
when
we
introduce
some
additional
features,
for
example,
something
the
heading
serialization
format
or
the
heading
requests.
C
And
that
kind
of
brings
me
back
to
a
the
heading
of
a
certain
weight.
If,
if
we
were
to
add
a
parent
to
this
entire
thing
that
I
I'm
not
sure
of
what
the
title
would
be,
but
if
everything
that
exists
currently
is
under
a
certain
heading
that
somehow
differentiates
it
from
things
like
websockets
and
other.
What
are
the
protocols,
then,
then,
I
think
that
stuff
is
fine,
because
if
you
have
serialization
as
a
first
level
heading,
then
it
applies
everywhere
in
the
spec.
C
A
Yeah
that
makes
sense.
Interestingly,
serialization,
I
think,
is
one
of
the
things
that
would
actually
be
common.
So,
like
the
media
types,
I
think,
makes
sense
to
be
its
own
chapter,
and
originally
I
actually
had
quite
a
lot
of
the
rules
were
in
the
media
types
chat
to
start
with
and
then
I'd
sort
of
move
them
out
into
the
request
and
response
where
it
seemed
to
make
more
sense.
A
But
then,
when
we
start
thinking
in
terms
of
there
being,
you
know,
standard,
http,
request
and
response,
and
then
there
being
websocket
request
and
response
and
there
being
service
center
server,
sent
events,
request
and
response.
All
of
those
all
three
of
those
are
going
to
use
the
same
like
serialization,
most
likely.
A
A
B
A
really
hard
time
trying
to
come
up
with
a
term
that
describes
the
thing
that
we
currently
have.
A
A
C
One
is
what
we
were
just
discussing
here
as
far
as
a
you
know,
main
header,
for
all
of
this,
but
the
second
is:
how
do
we,
how
and
if
we
create
a
section
for
things
that
apply
to
everything,
if
you
say
serialization
will
apply
regardless,
then
you
know
that
that
should
not
be
under
whatever
header
we,
we
are
creating
right
now
it
should
be
in
a
common
section,
but
we
have
to
make
sure
that
it
will
be
common
in
the
future,
otherwise
we're
breaking
compliance.
A
Yeah,
I
agree,
but
I
wonder
whether
actually
the
concept
of
request
and
response
is
actually
correct,
as
it
is
currently
specified.
Potentially
and
then
there
might
be
another
chapter
that
is
more
like
stream.
A
So
there's
there's
a
request
and
then
there's
a
singular
response
which
works
for
what
we
have
and
then
there
might
also
be
a
stream
response
which
would
apply
for
subscriptions
and
for
stream
and
fur.
Sorry
stream
was
a
bad
choice
of
word
for
it
because
of
stream
interfere.
But
you
know
like
a
series,
a
series
of
responses
that
might.
A
That
might
be
it
because
when
you
have
service
and
events
right,
you
still
send
a
request
that
is
in
basically
the
same
shape.
It's
just
you're
using
the
server
center
events
like
request,
headers
and
you're,
sending
the
service
server
center
events
response
headers
as
well,
but
the
actual
response
payloads
are
the
same
as
they
would
have
been
over
a
traditional
http
request,
except
in
the
event
of
obviously
a
stream
or
a
subscription,
in
which
case
you'll
get
a
series
of
them,
but
they're
still
the
same
structure.
A
They
still
follow
the
same
rules,
they're
still
the
same
serialization,
so
it
might
be
that
actually
request
and
response
is
correct
and
what
we
end
up
doing
when
we
add
service
and
events
is
actually
we
remove
some
of
the
like
things
that
talk
specifically
about
headers,
for
example,
and
we
then
put
them
into
like
we
add
a
new
chapter
section,
sorry,
that
is,
you
know
traditional
http
requests
and
then
server
center
events
and
then
websockets
that
then
have
their
own
special
here's,
how
we
do
headers
here's,
how
we
do
this,
that
the
other
I
mean
websockets,
for
example,
is
quite
interesting
because,
though
you
can
send
headers
with
a
websocket
request,
you
can't
often
do
that
from
web
browsers.
A
Web
browsers
are
quite
restricted
in
what
they
can
do
with
web
sockets,
whereas
from
other
clients
like
command
line
clients,
they
can
do
more.
So
typically,
what
you
have
to
do
with
the
websocket
connection.
Is
you
have
this
like
initial
payload,
which
serves
the
same
purpose
as
a
header
but
has
its
own?
You
know
completely
different
security
rules
because
a
user
can
send
whatever
they
want
in
an
initial
payload.
A
So
I
mean
I'm
going
into
more
details
here,
but
the
point
is
the
the
payloads
in
it
after
that
point
would
still
be
the
same,
but
the
way
of
specifying
that
you
know
it
is
json.
Content
type
may
well
be
different,
so
that's
fun.
C
Yeah
I'll
agree
with
that,
and
I
also
think
that
the
more
we
discuss
this,
the
more
it
becomes
clear
that
there's
a
lot
of
things
with
respect
to
web
sockets
and
server
sent
events
and
whatever
else
that
we
would
not
know
whether
the
spec
as
written
today
works
with
those
things
without
a
lot
of
thought
and
discussion.
A
Let's,
let's
invite
dennis
dennis,
has
written
the
spec
for
the
the
new
websocket
protocol
for
graphql
and
also,
I
think,
the
spec
for
the
service
and
events.
B
But
I
think
I
think
it's
a
you
brought
up
a
good
point
about:
let's,
let's
go
back
to
the
example
of
serialization,
even
if
we
capita
keep
it
as
a
top
level
heading
right
now,
once
we
add
further
top
level
headings
which
may
have
different
opinions
about
how
serialization
must
be
done
or
perhaps
just
certain
aspects
of
serialization,
you
can
always
move
those
things
down
into
the
top
level
headings
which
then
have
their
own
section,
which
further
details
how
serialization
is
supposed
to
work.
That's
not
breaking
the
spec.
B
It's
just
moving
things
somewhere
else,
so
it
won't
be
as
stable
in
terms
of
things
are
written
under
this
heading
in
this
line,
but
semantically
it
will
still
be
the
same.
A
Yeah,
I
think
that's
good
to
keep
in
mind
in
general,
but
also
with
spec
nd.
It's
pretty
handy
in
how
it
generates
like
the
the
fixed
urls
for
headers.
So
so
long
as
you
keep
consistent
headers,
the
the
spec
md
links
will
be
the
same,
so
you
can
have
kind
of
the
same
link
carry
across
multiple
versions
of
the
spec.
Hopefully,
if
we
start
moving
things
around,
putting
them
under
different
headers
or
at
least
different
tiers
of
header,
then
the
links
will
change
and
we'll
get
broken
links.
A
It's
not
the
end
of
the
world.
Like
the
user
clicks
it,
it
doesn't
go
anywhere.
It
just
sends
them
to
the
top
of
the
spec,
and
then
they
have
to
find
the
place
again.
But
if
we
can
maintain
those
permalinks,
that
would
be
better.
C
A
Okay,
cool.
I
have
added
an
action.
I'm
gonna
test
that
to
myself,
so
I'm
gonna
reach
out
to
to
dennis
and
have
him
read
over
this
we'll
get
this
merged.
I
will
also
make
the
the
changes
that
we
discussed
at
least
the
ones
that
I
mentioned
in
the
thread
itself.
If
there's
anything
else,
you
think
should
be
in
there
comment
on
the
pull
request,
because
I'm
not
sure
if
we
have
full
notes
in
these.
The
notes
from
this
cool.
A
Yeah,
okay
and
then
from
there
should
we
we
should
at
least
get
david's
feedback.
I
might
have
a
go
and
see
if
I
can
write
a
few
notes.
That
would
make
david
happy
in
fact
I'll.
Add
that
as
an
action
as
well.
A
Well
I'll
have
a
go
at
doing
that
as
well,
and
then,
if
we
can
get
enough
confidence,
then
maybe
we
should
raise
it
at
the
the
next
working
group
and
buy
next.
I
don't
mean
this
coming
one
I
mean
the
one
in
august,
so
it
was
an
aim
to
raise
this
at
the
august
working
group.
How
does
that
sound
to
raise
work?
Sorry
to
raise
the
merged
version
of
the
graphql
over
http
spec
at
the
august
graphql
specification
working
group,
the
top
level
working
group.
C
Sounds
good?
What
then,
would
be
discussed
at
the
july
working
group.
A
The
graphql
spec
working
group,
the
main
one
yeah.
I
wasn't
planning
to
raise
anything
that
I
might.
I
might
just
comment
that
we
are
getting
closer.
C
Okay,
yeah,
I
thought
I
saw
something
yeah,
just
a
small
update
you
had,
but
I
didn't.
I
didn't
know
exactly
what
your
thoughts
were.
As
you
know,
what
would
be
brought
up
there?
Would
we
share
the
spec?
Would
we
just
discuss
the
idea
of
a
watershed,
or
is
there
more
to
it
than
that.
A
Yeah
good
good
question
yeah.
I
was
just
basically
planning
to
give
a
state
of
this
update.
We
we
commented
on
this
at
the
the
main
working
group
recently
that
the
subcommittees
do
things,
but
they
haven't
really
been
told
how
to
then
bring
that
information
back
and
so
either
lots
of
stuff
goes
on
and
the
main
working
group
just
doesn't
know
about
it,
or
things
are
not
going
on
and
the
great
working
group
doesn't
care
about
that
either.
A
So
I'm
going
to
try
and
make
a
point
of
reporting
back
from
this
working
group.
At
least
you
know
from
time
to
time,
small
updates
and
I'd
like
to
encourage
the
other
sub
committees
to
do
so
as
well,
so
I'm
kind
of
trying
to
model
that
a
little
bit
but
yeah.
Basically,
I
just
wanted
to
give
them
an
update,
say
you
know:
we've
got
it:
we've
kickstarted,
it
got
it
working
again.
A
Here's
our
current
status
and
if
our
plan
at
the
end
of
this
meeting
is
to
say
we
want
to
present
this
at
the
next
working
group.
I
will
tell
them
at
this
coming
working
group.
We
are
intending
to
present
it
next
working
group,
so
give
us
a
week
or
two
to
get
the
final
edits
in,
but
then
give
it
a
good
read
before
the
next
working
group,
because
it
would
be
great
to
get
your
your
feedback
at
that
point.
A
B
One
thing
that
I
think
we
could
do
until
next
time:
some
go
through
the
existing
issues,
and
I
see
that
we
have
two
milestones
in
the
in
the
project:
one
being
posts,
1.0
release
and
one
being
the
1.0
release,
milestone
and
yeah,
and
one
is
september
2020,
which
I
don't
think
anyone
cares
about
anymore
yeah.
B
C
Still
left,
that's
a
good
point.
I
think
that
we
should
have
before
we
present
at
the
august
main
working
group
meeting.
We
should
have
our
issues
under
control.
Just
you
know,
like
a
professional
heir
to
this
group.
A
You
I'm
muted
another
comment
on
yeah.
I
agree
another
comment
in
terms
of
structure
is
we
wanted
to
adopt
spec
nd,
which
I
believe
we
have
done?
We
are
using
spec
md
syntax
in
various
places.
A
Exactly
yeah,
this
is
the
top
one
I
noticed,
but
also,
if
you
look
at
the
main
graphql
specification,
the
different
sections
are
in
different
files,
so
I
think,
as
part
of
as
doing
that,
issue
number
eight
spec
md.
I
think
I'll
split
up
the
the
document
into
those
the
current
sections,
the
ones
that
we
currently
have
so
I'll
give
them
actual.
You
know
section
numbers
just
like
we
do
for
the
main,
the
main
graphql
specification.
A
It's
not
particularly
large,
but
we
are
using
sections
and
since
that's
how
the
graphql
spec
works,
I
figure
it
makes
sense
to
just
copy
the
same
pattern.
Like
one
of
our
sections,
I
mean,
if
you
look
at
the
graphql
spec,
the
introduction
section
is
like
I
don't
know,
30
lines
of
markdown.
That's
it
in
that
file
and
ours
would
be
similar
like
the
the
content.
Type
section
is
again
small.
A
It's
just
in
terms
of
being
consistent
as
we
extend
it
over
time
having
it
in
separate
sections,
may
make
it
easier
to
edit
as
well,
but
mostly
just
in
terms
of
consistency
with
the
spec
itself.
Sure
yeah.
A
B
So,
who
can
actually
go
through
the
issues
and
close
them,
or
I
can
do.
B
Because
I
don't
have
permissions,
I
can
take
that
on
okay.
B
Should
we
so
are
the
I
guess
the
september
22
milestone
is
something
we
can
definitely
close,
but
are
there
any
other
milestones
we
we
might
add,
or
perhaps
any
labels
we
might
add,
to
organize
the
issues,
something
that
you
can
think
of.
A
I,
like
the
two
milestones
other
than
september
2020.
Obviously
I,
like
the
other
two
milestones.
It's
basically
very
clear
like
this
is
the
stuff
we
need
to
get
done
before
we
release,
and
this
is
the
other
stuff,
so
I
think,
whilst
you're
going
through
them
gabriel,
if
you
can
make
sure
that
everything
is,
is
in
the
right
milestone
according
to
what
our
intent
is
now,
which
may
be
different
from
our
than
10
like
two
years
ago.
A
That
would
be
good,
and
but
I
don't
think
we
need
any
more
milestones
for
now.
I
think
we
should
just
aim
to
get
that
version.
One
release
milestone
complete,
hopefully
by
the
august
graphql
spec
working
group.
C
Yeah,
I'm
fine
with
that,
and
I
think
that
the
thing
with
milestones
is
that
that's
easily
changed
as
we're
moving
forward.
The
post
1.0
release
could
become
multiple
milestones
in
the
future
agreed.
B
B
B
C
I
don't
know
if
I
can
copy
them,
but
recreating
them
is
not
that
difficult.
A
Okay,
ideally,
if
they
can
be
identical,
then
the
the
links
will
be
basically
the
same,
like
issue
templates
will
work
the
same
things
like
that:
you'll
be
able
to
share
them
between
the
two
things
and
that
can
be
problematic
with
emojis
if
they're,
not
exact,
copies
yeah.
So
if
you
have
any
issues
with
that,
just
ping
me
and
I'll
take
over
that
task.
If
you
need
me
to.
C
A
A
A
I
guess
we
need
to
find
one
that
david
can
attend,
really
that
david
and
dennis,
if
we
can
get
them
both
to
attend
one.
That
would
be
ideal.
C
Agreed-
and
I
I
don't
know
that
it
matters
for
any
of
us
three
so
far,
whether
we're
on
the
same
schedule
right
now
or
not,
so
we
can
make
this
ad
hoc,
like
we
did
this
time.
Okay,
let's.
A
Go
ad
hoc
I'll
see
if
I
can
find
a
time
that
works
for
both
david
and
dennis
and
then
we'll
go
from.
There
sounds
good
okay,
I'll
action
myself
on
scheduling
the
next
meeting
as
well,
then
yeah,
all
right,
fantastic.
B
I'll
definitely
try
to
be
there,
but
I
don't
think
I
have
something
particularly
important
to
contribute.
Apart
from
my
feedback,
so.
A
Well,
it's
always
recorded
and
and
put
on
youtube
anyway,
and
you
know
asynchronous
feedback's,
always
valuable
too,
sometimes
more
valuable,
because
you
can
go
back
and
reread
it
so
yeah
fantastic!
Well.
If
we
can
make
it
so
we
can
all
attend
I'll,
try
that,
but
otherwise
yeah
it
would
be
good
to
get
another
meeting
in
maybe
quite
soon,
actually
like
sort
of
two
to
three
weeks
time,
yeah,
so
that
we
can
get
as
much
done
as
possible
before
the
august
working
group.