►
From YouTube: CNCF Serverless WG Meeting - 2019-06-20
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
B
A
Typing
that
all
over
the
place,
I
apologize,
it's
fine.
Where
was
I,
you've
lost
the
train
of
thought.
Ok,
here
we
go
3
after
let's
going
to
get
started.
One
thing
I
forgot
to
mention
that
actually
ages
ago
is,
if
you
guys,
can't
make
the
call
because
of
a
public
holiday.
Let
me
know,
because
I
do
treat
those
differently
than
just
your
being
a
slacker
and
going
on
vacation.
I
do
count
the
official
holidays
as
still
present.
So
that
way
you
don't
lose
voting
rights
because
of
it.
A
In
fact,
if
you
have
a
lot
of
vacation
like
some
of
you
guys
in
Europe,
have
you
actually
made
gaining
going
rights
because
of
it
so
I
didn't
want
you
guys
be
penalized
because
you're
on
vacation
or
because
of
holidays?
So
just
let
me
know,
for
example,
Vlad
and
Clemens
today
are
tagged
with
that.
Luckily,
I
don't
think
it
matters
much
because
we
don't
actually
do
votes
very
often
and
usually
they're
landslide
when
we
do
vote
so
anyway.
Just
let
you
guys
know
that
you
should.
Let
me
know
all
right.
A
Let's
talk
about
some
a
ice.
First
of
all,
Thomas
had
an
AI
to
talk
about
when
we
do
or
do
not
need
the
content-type
the
cloud
of
encanta
type
attributes
the
spec
now
has
this
text
in
here.
That,
in
my
opinion,
covers
it,
but
I
want
to
make
sure
you
guys
are
okay
with
me
close
in
this
action
item.
So
I'll
give
you
guys
a
second
just
to
read
that.
A
Is
there
anybody
who
disagrees
so
we
can
close
this
action
item
and
at
this
bit
text
in
the
spec
covers
it:
okay,
cool
now,
Michael
I,
believe
slicing.
His
pain
hasn't
been
on
the
call
a
very
long
time
and
he
actually
volunteered
reduce
investigation
to
open
census.
But
unless
somebody
on
the
group
wants
to
volunteer
to
pick
up
that
work,
I'm
inclined
to
close
this
action
item,
does
anybody
wants
to
volunteer
or
object
to
that
action?.
A
Okay,
I'll
do
that
then
Jules
I
believe
he
was
from
docker.
He
was
gonna
write
a
proposal
for
benchmark
framework,
but
he's
been
has
enough
patience
doing
our
calls
and
quite
a
long
time
so
I'm
gonna
try
to
see
if
I
can
reach
out
to
him,
but
otherwise,
if
I
don't
hear
back
from
I'm,
just
gonna
close
this
action
I'm
because
I
think
he's
kind
of
vanished
and
then
finally,
Scott
Rachel
had
an
AI
for
an
official
text
around
the
subject:
PR,
if
you're
so
inclined.
A
D
A
Okay,
cool.
Thank
you,
I!
Think!
That's
it
in
terms
of
actions
you
can
deal
with
next.
Is
there
any
objection
to
cancel
in
the
call
on
the
July
4th
I
know
it's
not
a
holiday
for
everybody,
but
I.
Think
enough.
Us
folks
be
absent
that
we
may
not
have
quorum.
So
it's
okay
to
cancel
July
4th
further
buddy,
all
right
cool.
Thank
you
all
right.
Community
time
is
there
anything
from
the
community
people
like
to
bring
up
so
I'm
sorry,
Jude
your
hands
up.
What.
A
Think
this
was
trying
over
we're
at
a
face-to-face
and
Jude
showed
up
and
I
believe
docker
wanted
some
sort
of
framework
to
test
whether
service
implementations
adhere
to
something.
The
fact
that
it
says
benchmark
leads
me
to
believe
it
wasn't
functional.
It
was
more
performance
related,
but
I
honestly
cannot
remember,
but
he
was
supposed
to
come
back
with
a
proposal
to
actually
explain
what
he
was
looking
for
and
he
never
did.
But.
A
F
A
A
C
But
I
like
coming
on
the
open-
oh
okay,
sorry
yeah!
So
anyway,
uh-oh
possessing
itself
is
probably
not
very
related
to
cloud
events
as
it's
a
library
for
actual
actual
libraries
for
collecting
metrics
and
traces
parts.
We
have
a
distributed
tracing
extension,
but
is
there
any
guidance
as
to
the
metrics
that
the
SDK
should
support
as
I
I
guess?
The
SDK
should
support
collecting
metrics.
G
D
C
It
is
a
completely
honest
Takeshi
in
my
mind,
I.
Just
think
that,
since
we
have
SDK
guidelines,
if
some
of
them
do
support
metrics
for
events,
something
they
should
probably
be,
the
metric
are
tags
or
names
or
whatever
you
want
to
call
them.
Label
should
probably
standardized
in
the
SDK
guidelines
so
that
they
aren't
dependent
on
language.
Would.
F
A
C
A
Okay,
alright
moving
forward
SDK,
stuff
I
know
we
haven't,
had
a
phone
college,
probably
isn't
anything
to
say
there
other
than
we
will
have
a
call
right
after
this
one
for
30
minutes
best
we
can
I
know
Clements,
obviously
can't
make
it
he's
out,
but
Mark
Scott
or
anybody
else,
we're
gonna
stay
case
again.
We
can
meet
it
because
I
know
there
were
some
topics
actually
class
I.
Think
you
had
a
topic
you
want
to
talk
about
to
cook
on
is
next
week
the
slides
are
available.
A
A
Let's
sequent
forward,
alright
incubator,
we
had
started
about
last
week.
I
think
there
was
one
person
who
questioned
whether
we
should
go
for
incubator
status:
sweet
because
it
wasn't
unanimous.
We
started
boat
so
far,
but
he
voted
offline
voted.
Yes,
is
there
anybody
on
the
call
days,
I,
don't
think
he's
gonna
check
some
his
ass.
This
way
is
there.
Anybody
here
objects
to
going
forward
with
things
better
status.
A
Okay,
so
we'll
just
do
that
much
easier
that
way:
okay,
so
the
next
step
in
the
process.
As
far
as
I
understand,
it
is
to
put
together
a
formal
proposal
which
is
I
think
just
that
PowerPoint
deck
for
the
TLC
I
think
I
can
take
that
action
and
start
winning
it
together,
and
then
you
guys
can
obviously
review
it
and
help
tweak
it.
The
biggest
ask
I.
A
C
Are
you
going
just
I
think
it's
been
quite
hard
to
find
names
for
this
3m
users
listening
to
the
calls
the
past
few
months,
I
think
a
big
part
of
that
is
the
fact
that
the
expect
is
clearly
changing
a
lot
in
the
open,
three
and
maybe
incorporate
forth.
There's
been
a
lot
of
changes.
For
example,
we
haven't
implemented
cloud
events
for
you
to
that
reason,
and
we
will
be
implementing
them
soon,
assign
fairly
convinced
that
respect
is
not
changing
a
lot
anymore.
Yes,.
B
A
To
be
honest,
I
am
I
suspect.
We
may
not
have
that
many
issues
finding
them,
because
I
know
that
there
are
some
products
out
there
that
they
use
it
today.
I
mean
all
you
gotta
do
is
find
a
user
of
eventing
and
Kay
native,
and
you
can
as
long
as
I,
going
to
put
their
name
out
there
publicly
that
I'll
count
because
Kay
native
uses
clown
events,
so
I
think
I
think
we'll
be
able
to
do
I
just
need
to
people.
Thinking
me
names.
Basically,
what.
A
A
All
right,
be
one
put
our
discussion
now.
I'll
have
to
talk
about
here.
Other
than
I
was
using
this
sort
of
track.
How
things
are
going
so
just
a
reminder
that
there
are
five
issues
out
there
that
need
PRS
associated
with
them
or
proposed
to
proposal
to
close
them.
These
four
people
or
find
people
I
guess,
are
sort
of
owners
of
those
issues
or
a
volunteer
to
do
something.
A
I
know,
if
suppose,
that
what
Christophe
you
volunteered
to
help
Scott
out
and
I
was
hesitant
to
put
your
name
here,
but
since
the
PR
isn't
there
yet
I
thought
I
just
use
as
a
reminder
for
everybody
that
we
are
waiting
for
PRS
or
some
sort
of
resolution
of
those
issues.
There's
just
the
v1
issues,
and
there
are
sorry.
C
A
A
A
If
we
can
maybe
lots
of
things
today
and
just
remind
her,
did
it
again
de
beanie
and
Clemens,
you
guys
have
a
to
P
ours
that
need
update
for
V,
one
point
for
the
tribe
he
1.0
status
or
bucket
and
again
where
everybody
agreed
they
were
still
trying
within
hopefully
about
two
weeks
or
so
to
get
to
the
point
where
we
at
least
do
a
release
candidates
for
one
point:
oh
alright!
So
with
that,
let's
see
if
we
can
close
this
puppy
today,
Oh.
A
G
A
I
so,
in
my
opinion,
between
that
and
the
fact
that
I
think
you're
pulling
in
changes
that
are
obviously
are
not
related,
your
stuff
I
look
at
those
is
more
just
like
syntax
or
rebased
issues
that
should
not
really
affect
whether
we
approve
this
or
not.
To
be
honest,
and
so
what
I'd
like
to
do
is
ask
the
group
if
they
have
any
questions
about
this,
if
it
have
any
concerns,
because
if
not
what
I'd
like
to
do
is
conditionally
approve
this,
assuming
the
editorial
type
changes
can
get
made
and
then
offline.
A
A
A
I
know
Clements
had
a
lot
of
opinions
on
this
one
and
since
he's
not
on
the
call
and
I
don't
believe
James
is
on
the
call
either
I'm
inclined
to
defer
this
one,
unless
you
guys
have
any
really
strong
opinions.
You
want
to
talk
about
that
one
right
now,
okay,
so
let's
defer
that
one.
In
that
case,
Klaus
you
get
to
go
next.
Okay,.
I
If
I
don't
intend
to
somehow
modify
or
delete
an
attribute
are
supposed
to
fall
about
them.
So
that's
exactly
a
nice
discussion.
We
had
then
as
a
follow-up
to
this
pull
request
and
in
the
comments
how
to
express
this
best,
I
decided
to
just
use
the
wording
that
was
already
there
with
a
sadly
ignore
and
describe
that
an
intermediary
for
an
intermediary
site.
The
ignoring
an
optional
attribute
means
that
it
must
forward
it
but
yeah.
I
So
there
have
been
some
other
proposals
just
to
state,
for
example,
that
an
intermediary
should
or
a
strongly
encourage
to
forward
optional
attributes
or
an
eery
that
is
not
configured
explicitly
configured
to
do
otherwise,
as
must
forward
attributes.
So
there
are
several
proposals
in
the
comments
right
now:
I
think
the
other
part
and
the
primary
modified
was
mostly
to
introduce
also
the
term
knowledge.
So
the
producer
consumer
and
intermediary.
A
A
C
H
A
Think
it
just
at
some
of
the
general
direction
is
that
a
fair
summary
for
a
buddy
okay?
So
maybe
Klaus,
who
do
is
take
the
exact
words,
nothing
offline
and
and
maybe
prove
it
offline
if,
if
need
flg
teams,
otherwise
worst-case
scenario,
we'll
revisit
it
in
next
week,
with
the
exact
wording.
Is
that
sound,
fair,
I.
I
A
I
A
A
A
1.0
we've
completed
all
the
criteria
that
we've
defined
up
here
and
we
have
completed
as
many
of
the
Tri
for
V
1.0
tag,
dishes
and
pr's
as
possible.
There's
no
fixed
amount,
it's
just
whatever
we
get
down
the
time
period
we'll
get
in
there,
but
thanks
to
Christoph
suggestion.
I
added
some
wording
here
that
talked
about
how
these
changes
are
expected
to
be
non-breaking.
Changes
in
nature,
they're
not
meant
to
really
change
much
of
the
semantics.
A
It's
more
of
a
clarification
type
stuff
yeah,
that's
not
to
say
that,
as
we
do,
our
verification
testing,
we
mean
we
won't
introduce
breaking
changes.
Obviously
we
can
because
they
don't
come
to
1.0
yes,
but
these
traivor
1.0
issues
and
PRS
are
meant
to
be
more
clarification
on
nature,
more
than
anything
else
or
additional
binding
specs.
We
have
a
couple
of
those
in
the
pipeline
and
then
a
one
point
though
I
put
in
all
the
other
stuff.
You
know
things
that
are
not
required.
J
A
A
A
J
A
Does
and
maybe
now
that
you're
mentioning
all
this,
maybe
it
would
be.
Maybe
it's
a
mistake
for
me
to
label
this
as
one
point
one
and
I
should
find
some
other
way
to
describe
this
as
a
TBD
kind
of
a
thing,
because,
obviously,
based
upon
what
we
do
in
terms
of
issues
are
resolved,
we
may
or
may
not
have
to
go
to
one
point,
one
ever
or
at
least
not
for
a
long
period
of
time
and
everything
could
be
process
related
stuff
right.
A
C
A
Yeah
it
only
they're
version
transports
are,
though,
so
that's
that's
kind
of
that's
gonna
be
kind
of
an
interesting
one,
and
maybe
that's
maybe
we
need
to
discuss
that.
As
part
of
you
know
this
type
of
discussion
or
something
like
that,
but
I
don't
want
to
battle
on
this
with
a
lot
of
things.
So
let
me
do
this.
Are
there
any
objections
with
the
general
direction?
I'm
headed
here
in
particular
in
here?
A
Okay,
I'm,
not
gonna,
prove
the
PR
I'll
work
on
this
section
down
here,
and
maybe
we
can
talk
about
it
again
next
week,
but
I
definitely
don't
want
to
rattle
on
this
one
cuz.
This
isn't
worth
it.
Everybody
knows
where
we're
going
conceptually.
We
just
gotta
find
out
the
right
words
to
put
it
on
paper.
Okay,
so
let
me
click
on
that
one
guy!
A
Okay,
now
this
one
was
an
issue
as
originally
opened
up
by
the
other
Doug.
Now
I'm
not
gonna,
ask
to
it
on
this
because
it
was
just
opened
a
couple
hours
ago
or
maybe
an
hour
so
ago,
but
I
just
want
to
draw
your
attention
to
it
and
make
sure
or
I
want
to
get
a
sense
for
how
people
feel
about
the
general
direction.
A
A
If
and
it's
just
to
make
it
clear
that
the
schema
that
you're
referring
to
isn't
just
about
data,
it
could
technically
about
other
things.
If
they
choose
to
talk
about
those
other
cloud
event
attributes,
it
seemed
like
a
very
reasonable
thing
to
me
and
I'm
like
I
said:
I.
Don't
wanna
vote
it
on
today,
but
I
wanted
to
get
a
sense
from
the
group
as
to
whether
you
guys
are
okay
with
that
general
direction
or
not,
because
if
not,
then
we'll
go
back
and
rethink
it.
Otherwise,
we'll
wait
till
next
week
to
do
a
vote.
E
J
J
C
J
C
K
What
I
see
this?
It
was
trying
to
utilize
an
existing
attribute
rather
than
to
define
another
one,
but
it's
about
utilizing
cloud
events
as
a
an
umbrella
format,
where
more
domain-specific
schemas
could
be
accommodated
by
it.
But
those
domain-specific
schemas,
like
I'll,
give
an
example
gs1
which,
as
a
event,
format
called
EPSA
CPC
is
that's
really
focused
more
on
location,
tracking
of
products
and
a
supply
chain.
You
know
they
have
a
format
that
could
be
accommodated
in
here,
but
the
it's
more
than
just.
K
The
data
attribute
that
would
have
to
conform
to
the
abscess
schema.
It
would
have
to
also
utilize
the
other
contextual
attributes
of
cloud
events
in
a
certain
way
to
ensure
that
it
complied
to
anybody
that
was
producing
or
consuming
those
episodes
of
ents,
for
example,
with
an
abscessed.
A
time
is
a
required
attribute,
not
optional
type
would
be.
If
you
look
at
the
cloud
events
attribute
descriptions,
there's
it's
it's
very
general
its
intended
to
be
that
way
to
accommodate
a
lot
of
different
use
cases
and
there's
examples
that
are
used
under
each
of
those
attributes.
K
And
if
you
go,
if
you're
adhering
to
a
more
constraining
format,
you
want
to
lock
down
the
you
know
what
those
those
attribute
values
can
be
so
that
they
can
accommodate
that
specific
format.
So
it's
beyond
just
data,
so
this
so,
but
by
extending
this
existing
schema,
our
schema
URL
attribute
to
accommodate
other
than
just
data
than
it
is
moving
it
out
of
that
date.
Those
data
specific
attribute
categories.
It's
moving
it
up
to
the
level
of
the
cloud
event
version.
A
E
A
My
hands
up
right
and
I
had
them.
It
I'm
torn
on
this
one
as
well.
For
a
couple
of
reasons.
One
is
the
URL
that
we're
pointing
to
here,
obviously,
and
a
lot
of
people's
minds.
I
think
they
merely
jumped
to
something
like
an
XML
schema
doc,
where
it's
strictly,
you
know
xst
file
and
then
that's
all
it's
there.
But
technically
this
could
point
to
just
about
anything.
A
In
particular,
it
could
technically
point
to
like
a
word
doc
or
a
web
page,
and
as
part
of
that
word
doc,
it
could
have
the
XS
d
file
and
that's
what
you're
supposed
to
use
to
to
verify
the
the
shape
of
the
data
or
actually
with
even
within
an
XS
d
file.
If
you
have
a
comment,
you
could
have
a
comment
that
says,
oh
and
by
the
way,
if
this
payload
is
being
sent
as
part
of
a
cloud
events,
the
type
leave.
A
The
cloud
of
that
type
attribute
should
look
like
this
or
that
the
time
attribute
is
no
longer
optional.
It's
not
required
right,
I,
I,
don't
know
how
I
feel
about
that.
But
I
could
see
that
being
how
this
can
be
done
so
you're,
not
necessarily
breaking
existing
tooling.
That
is
assuming
this
only
talks
about
the
body.
I'm.
Sorry
I'm
talking
about
data,
but
then
other
people
understand
that
there
are
cases
where
goes
further.
It
knows
what
to
look
for
to
say.
A
A
The
the
other
part
that
I
really
wanted
to
ask,
though
about
for
Doug,
is
whether
the
type
itself
could
be
used
as
this
sort
of
schema
thing
that
you're
looking
for,
because
a
lot
of
the
cloud
events
that
we're
sending
or
all
the
quadrants
we
send,
you
don't
have
a
type
and
a
lot
of
times,
they're
prefixed.
With
the
same
you
know,
set
of
or
identifiers,
for
example,
to
get
up
stuff.
They
all
start
with
calm
that
github
and
I'm
wondering
whether
that
alone
should
be
sufficient.
A
For
someone
to
be
able
to
say,
oh
I
know
that
github
crowd
events
have
these
additional
requirements,
because
there's
some
document
that
says
that
therefore
I
don't
actually
need
to
modify
this
URL.
Just
the
prefix
of
the
type
would
be
sufficient
for
me
to
know
those
additional
constraints.
Those
are
sort
of
things
are
right
to
mine.
I
was
Brian
Doug.
If
you
had
a
comment
on
I'm
trying
to
reuse
that
the
prefix
and
the
type
would
be
sufficient
for
you,.
A
C
Yeah
just
quickly,
I
think
the
first
thing
you
were
talking
about
just
pointing
to
a
word
doc
or
doing
comments
inside
the
schema
I
myself,
I'm,
not
enthused
about
encouraging
that
kind
of
behavior,
because
I
know
that
I
would
miss
99%
of
those
either.
The
whole
scheme
are
already
specific
comments
about
some
other
attributes
in
the
cloud
event,
because
they're,
not
machine
readable.
C
If
someone
adds
a
comment
to
they
schema
afterwards,
I'm
not
gonna
notice
it
ever
yeah,
and
the
other
thing
is
that
the
type
does
already
big
take
practically
what
you
will
find
in
the
cloudy.
But
that's
just
off
the
wire
side.
Channel
communication
github
will
most
likely
document
their
own
extensions,
what
they
use
and
stuff
like
that.
So
that
already
happens,
that's
just
not
respect
out
in
doc,
so
that
doesn't
require
changes
in
that
sense
right,
but
I
think
this
is
kind
of
right.
A
Okay
will
tell
you:
what
did
you
wanna
respond
to
that.
A
A
Let's
see
how
much
of
an
offline
discussion
we
can
have,
and
maybe
we
can
figure
out
how
we
want
to
move
forward
on
this
one
before
next
week's
call,
but
I
just
want
to
bring
this
once
you
guys
attention,
because
this
I
think
is
the
last
PR
tag
with
1.0
as
of
right
now,
so
I
want
to
make
sure
people
pay
attention
to
it
and
think
about
it.
Okay,
how
about
let's
work
it
through
the
issue
or
I'm,
sorry
to
the
PR
itself,
the
moving
forward?
A
So
it
seems
to
me
that
it
would
be
a
mistake
for
us
to
drop
one
of
them
entirely.
That's
not
to
say
that
we
couldn't
change
our
specifications,
because
I
think
some
of
the
specs
right
now
require,
like
HTTP
I,
think
it
requires
the
receivers
support.
Both
we
could
change
that
requirement
that
we
wanted,
but
I
think
it's
a
different
issue
relative
to
this
particular
issue,
about
the
option
of
dropping
one
of
the
two
I.
A
C
D
D
A
Going
to
say
that
that
is
the
exact
reason:
I've
been
a
very
enamored
with
the
binary
mode
right.
If
you
have
an
existing
message
flowing
around
I,
don't
have
to
change
my
code.
That
processes
it
anymore.
All
I
have
a
well
have
are
just
extra
headers
that
I
may
or
may
not
want
to
deal
with.
Nothing
else.
Changes
I,
love
that
so
and.
A
Okay
Clemens
isn't
here,
but
let
me
see
if
this
one
is
in
a
state
where
we
could
quickly
approve
it,
because
I
think
he
addressed
everybody's
concerns,
I'm
just
saying
yeah,
so
I
don't
think
he
made
any
material
changes
since
last
week.
I
think
he
maybe
maybe
just
made
some
minor
syntactical
editorial
type
changes
here.
I'll
give
you
guys
a
second
to
review
and
fresher
memory
about
what
he
said
here.
A
A
C
That
conflict
a
bit
the
transport
biting
in
vagrant
form
of
encoding
sections,
because
the
amended
form
an
encoding
section
should
define
how
the
information
well
off.
The
base
specification
together
with
the
chosen
extensions,
is
encoded
for
mapping
but
actually,
for
example,
in
the
case
of
the
binary
encoding.
Oh
that's
a
different
encoding,
I!
Guess:
okay,
maybe
I'm
wrong,
so
the
HTTP
binary
encoding
does
actually
the
Evan
format
encoding
part
in
the
transport
binding.
So.
C
C
A
Well,
okay!
Well,
let
me
put
this
way.
Would
you
prefer
to
get
that
resolved
before
we
merge
this?
Or
would
you
like
to
have
a
follow-up
here?
I
think
it's
fine,
so
have
a
follow-up.
Okay,
do
me
a
favor,
then
open
up
a
port
request
to
do
that.
Yeah,
okay,
cool!
Thank
you
and
actually
just
a
reminder
of
everybody.
It
especially
when
it
comes
to
things
like
the
primer
feel
free
to
make
edits
and
destroy
pr's.
As
you
see
fit,
none
of
this
stuff
is
probably
perfect
as
it
right
now.
A
I
originally
had
some
text
talks
about
how
a
single
occurrence
could
result
in
more
than
one
events
and
I
actually
had
that
text
down
here,
and
it
was
a
little
confusing
because
it
kind
of
applied.
That
type
varies
only
when
you
have
multiple
occurrences
and
that
wasn't
the
intention,
so
I
moved
to
that
little
sentence
up
here
into
the
definition
of
events,
to
make
it
clear
that
a
single
occurrence
may
result
in
more
than
one
event
that
way:
it's
not
tied
to
the
type
stuff
anymore.
So
I
don't
think,
actually
changed
anything
from
last
time.
A
A
A
A
B
A
Kind
of
lingered
and
since
he's
off
doing
some
other
exciting
stuff,
I
decided
to
follow
through
on
it
forum.
Basically,
what
he's
talking
about
here
is
trying
to
add
some
text
to
the
primary
that
makes
it
clear
that
transport
level
information
is
not
meant
to
go
inside
of
the
cloud
event
itself,
in
particular
the
transfer
level,
routing
information.
So
it's
little
paragraph
here,
just
it's.
What
section
was
this
one?
A
A
Okay,
that's
just
part
design
goals.
Okay,
so
basically
he
introduced
the
notion
of
metadata
transport
level,
information
not
being
part
of
the
cloud
event
spec,
and
then
he
points
it
down
to
the
non
goals
section,
which
gives
a
much
more
detailed
explanation
here.
I'll
give
you
guys
a
second
to
look
that
over
in
case
you
haven't
read
it
recently.
A
J
A
A
Got
it
okay,
Fabio
is
not
on
the
call,
but
have
people
had
a
chance
to
look
at
his
Avro,
spec
I.
Think
there's
some
minor
or
syntax
things.
I
should
be
full,
so
zero
point
forward
with
my
progress.
But
aside
from
that,
it
looked
good
to
me,
but
I
know
nothing
about
this
protocol,
so
I
was
looking
at
it
straight
from
iCloud
events
perspective.
A
L
L
If
it's
a
binary,
binding
you're
already
going
to
be
doing
this
serialization
part
of
your
application
and
then
attach
it
as
a
binary
attachment.
So
if
it's
a
binary
attachment,
that's
really
outside
of
the
you
know,
the
cloud
event
spec
that
would
be
again
back
to
I
would
bind
it
and
somewhere
in
the
header
to
indicate
perhaps
that
this
is
an
admiral
binding.
But
I
may
want
to
actually
put
what
you
know
all
kinds
of
additional
things
into
it,
and
I
probably
wouldn't
be
worrying
about
serialization
of
things
such
as
headers
right.
A
C
C
If
that's
the
goal,
that
I
think
we
do
need
to
have
the
event
for,
and
that's
because
the
SDKs
will
need
to
the
specification
I
think
it's
part
of
a
question
whether
we
should
allow
someone
suggest
insert
if
the
SDK
should
probably
just
allow
someone
to
put
whatever
they
want
there.
If
it's
not
supported
the
emaan
format,
they
need.
L
A
So,
okay,
my
reading
of
what
we're
headed
here
is
your
concern,
isn't
about
this
particular
proposal
itself.
It's
a
higher-level
issue
and
right.
It's
okay
can
I!
Ask
you
to
open
up
an
issue
to
have
that
discussion
in
the
issue
itself,
because
I
don't
think
it's
like
fair
to
pick
on
me
on
Fabio's
PR
to
have
this
discussion
without.
A
L
But
this
is
actually
part
of
I.
Think
the
confusion
comes
back
into.
All
of
this
is
a
lack
of
examples
other
than
HTTP
for
the
transport
binding
to
the
actual.
You
know
SDKs.
So,
for
example,
in
the
Java
SDK,
we
have
taken
the
well
they've
done.
A
good
job
of
saying
here.
I
have
an
object
that
represents
all
the
parts.
L
According
to
the
specification,
the
header
properties
are
going
to
be
serialized
based
on
the
libraries
for
AMQP,
not
cloud
events
or
any
cloud
event
definition
and
the
payload
is
just
going
to
be
the
the
actual
method
event
itself,
which
I
don't
see
that
you
would
actually
take
the
entire
event
object
and
send
that
which
will
include
all
the
stuff,
that's
in
the
header
and
the
payload,
or
is
that
what
we
really
are
expecting?
Because
that
is
not
my
understanding
and
respect?
L
D
A
D
L
L
A
A
I
would
like
to
get
this
one
in
next
week,
if
possible,
because
I
don't
think
of
anything
that
controversial
in
there
aside
from
hinds,
is
a
higher-order
issue
which
you
said:
you'll
open
up
an
issue
about.
So
with
that,
let
me
go
back
and
do
a
final
roll
call.
Oh,
let's
see
Xavier.
Are
you
still
there?
Yes,
okay
and
Jim
I
got
you
William.
Are
you
there
still
lost
William?
What
about
Glenny?
Oh
I,
don't
see
the
macaw
or
Gilbert
okay
there.
Anybody
I
missed
for
real
call.
A
Okay,
in
that
case,
thank
you
very
much
and
if
you're
yes
to
Katie,
please
stick
on
the
call,
because
I
call
started
a
minute
ago.
Everybody
else
you're
free
to
go.
Thank
you
guys
very
much
for
a
very
productive
talk
later.
A
A
I
Yes,
also
to
record
what
exactly
it
was
about,
but
I
think
I
was
doing
some
recap
of,
but
you
know
at
when
we
were
preparing
the
demo
for
cube
corn.
We
burn
a
rush
and
I
was
now
looking
into
the
issues.
I
ran
into
over
that
preparation
and
I
think
yeah
exactly
so.
I
just
saw
on
and
the
go
SDK
that
I
mean
we
just
had
this
switch
from
this
string.
Representation,
I
think
so
for
Jason
I
think
wasn't
exactly.
It
was
something.
I
So
I
think
the
the
strings
and
the
HTTP
headers
supposed
to
be
json
encoded
before
when
we
switched
that
to
a
string
representation,
and
that
was
over
those
types.
We,
the
type
discussion,
I,
think
and
I
just
stepped
over
it,
because
the
chorus
decays
over
some
lines
of
code
we're
room
for
HTTP,
headers,
I
think
at
least
for
extensions.
A
I
I
Yeah,
so
that's
what
I
said
on
the
selection
I,
just
wonder
if
those
recent
changes
are
already
reflected
well
in
all
the
SDKs,
because
I
saw
in
the
go
SDK
wasn't
yet
done,
I
mean
it
was
very
fresh
that
change
and
and
I
said
it,
because
I
think
that
might
be
handy
to
have
some
common
test
events
to
send
and
receive
those
SDKs
and
see
if
they
all
work
the
same
with
those
SDKs.
Ok,.
A
So
I
think
I
understand
where
you're
headed
with
this
so
because
originally
I
think
when
you
pasted
this
issue
to
slack
to
me
or
whoever
it
was
I
thought.
Maybe
you
were
wondering
whether
there
was
a
problem
with
the
spec
but
really
you're
just
concerned
that
perhaps
all
the
SDKs
are
not
adhering
to
the
changes
we
made
in
0
3.
And
so
you
just
want
test
cases
or
some.
A
I
B
I
D
A
A
D
A
A
B
C
H
C
C
A
That's
way
too
long
ago:
okay,
okay,
so
do
have
an
issue
out
there.
Okay,
that's
good,
so
we
will
at
least
talk
about
at
some
point.
This,
however,
to
me:
okay,
this
type
of
1.0.
So
that's
good
okay,
so
we
will
talk
about
this
at
some
point:
cool,
okay,
so,
okay!
So
there's
two
like
to
this
one,
then
there's
one
is
that
issue
that
we
were
talking
about,
but
then
there's?
How
do
we
do
testing
to
make
sure
but
he's
correct?
A
What
do
you
guys
want
to
do
about
testings
I
know
this
has
come
before
like
in
this
381
issue.
How
do
you
guys
want
to
address
that?
I
think
that
actually
might
be
part
of
this
testing
and
verification
period
that
we're
talking
about
doing
before
we
go
1.0?
Is
it
someone
take
the
the
action
item
to
come
up
with
some
sort
of
test
harness
or
leave?
Maybe
a
test
client
or
something
like
that.
D
So
at
one
point,
I
actually
had
a
part
of
one.
The
truffle
is
you
you.
Unless
you
leverage
like
the
golden
SDK,
you
have
to
rewrite
an
entire
SDK.
We
possibly
could
do
this
with
like
pre
canned
responses
that
are
hand
edited
and
just
send
it
and
then
expect
a
certain
response
or
something
but
I
I
started.
Writing
one
I
realized.
It
was
exactly
the
code
that
I
was
writing
for
the
SDK
and
I
stopped
I.
I
D
I
think
I
think
the
right
answer
is
to
make
a
small
framework
that
is
specific
for
a
transport
that
you
can
record
or
create
new
encoding,
zhan
the
wire,
and
then
you
send
that
to
the
cloud
event
or
to
the
SDK
configured
with
a
certain
transport.
So
just
kind
of
like
pre
can
messages.
I
think
this
would
probably
get
us
pretty
far
so.
D
A
F
D
F
A
F
D
F
A
Just
yeah,
if
you
want
a
bit
twenty-year
guy,
if
you
want
your
SDK
to
be
to
participate
in
the
test,
you
got
to
provide
us
with
two
URLs.
One
is
the
URL
to
send
them
event
to,
and
you
know
the
URL
is
to
do
a
get
to
see
what
the
results
are
and
whenever
format
that
maybe
take
out
XML
is
an
example
right
that
way
the
tester
can
do
get.
Let's
see
how
I
could
do
a
post
followed
by
a
get,
and
he
should
be
able
to
verify
the
results.
Yeah.
D
A
C
E
D
D
A
D
A
Okay,
well,
it
sounds
like
if
this
isn't
necessarily
that's
hard
to
do
it's
just
a
matter
of
the
first
step.
If
someone
needs
to
actually
write
down
the
structure
of
this
entire
testing
framework
and
then,
if
we
all
agree
with
it,
we
can
go
off
and
implement
whatever
is
necessary.
There's
some.
If
there's
somebody
who
wants
to
take
the
first
passages
of
writing
down
what
the
framework
looks
like.
A
D
A
D
D
A
F
E
Yeah
just
a
general
comment
and
how
are
the
SDKs
meant
to
be
aligning
with
the
SDK
primer
or
spec
that
I
guess
Clemens
put
together
and
and
also
I
understand,
obviously
that
Jason
needs
to
be
supported,
out-of-the-box
but
I'm
curious
how
some
of
these
SDKs
are
expecting
to
work
with
something
like
protobuf,
where
they've
defined
either
you
know
the
entire
event.
Format
is
defined
in
proto,
so
I'm
I'm
a
little
bit
curious
about
what
the
thought
process
is.
There
I
can
see
in
clemencies
thing
he's
got
yo
providing
marshallers
for
the
data
payload
I
assume.
E
You
also
need
marshallers
for
the
extensions
as
well,
so
that
they
can
go
into
headers,
so
I'm
I'm
just
trying
to
understand
where
we're
going
with
that
stuff,
because
I
think
as
a
company
we're
on
the
verge
of
starting
to
actually
code
to
cloud
events,
but
from
what
I
can
gather
our
engineers
and
not
looking
at
the
SDKs
at
the
moment.
I'm
not
entirely
sure
why?
But
I
I
wanted
to
understand
your
cries
direction.
D
You
can
technically
provide
your
own
transport
and
you
can
provide
your
own
content.
I
call
them
codecs.
Were
you
inspecting
the
the
media
type
of
the
incoming
request
for
HTTP
or
the
data
encoding
for
the
cloud
event?
You
can
see
what
what
the
data
encoder
should
be.
So
you
can
select
a
decoder
that
matches.
E
Right
that
was
Alan,
Scott,
yeah,
I,
I,
guess
what
I'm
saying
is
that
in
the
spec
it
sort
of
says
you
should
define
a
cloud
event
object.
So,
though,
the
SDKs
have
gone
and
created
a
cloud
of
an
object
representation
in
some
cases.
But
when
you
talk
about
something
like
proto,
then
you
you,
all
you
really
want
to
do.
Is
layer
an
accessor
or
something
over
the
top
of
the
generated
proto
model
yeah,
your
your
SDK
is
not
going
to
own
the
proto
definition,
so
I'm
yeah.
E
Just
yeah
just
trying
to
get
a
sense
of
direction
and
is
the
SDK
spec
meant
to
be
adhered
to
from
a
pattern
perspective,
or
is
it
just
a
best
practice
sort
of
document.
E
D
D
A
A
Well,
that's
something
we
should
probably
get
fixed
then,
because,
if,
if
we
have
the
least
one
sdk
author
who
disagrees
with
the
doc
and
as
you're
doing
stuff
that
isn't
consistent
with
it,
then
they
kind
of
in
my
mind
it
makes
the
directly
sdk
doc
kind
of
pointless,
and
we
should
either
make
the
sdk
doc
align
with
what
you
guys
are
doing
with
what's
actually
being
implemented
or
kill
the
doc,
because
it
doesn't
provide
value.
I.
D
A
I,
if
I
learn
correctly,
one
of
the
reasons
we
came
over
the
SDK
doc
was
because
someone
at
some
point
said
gee.
Wouldn't
it
be
nice
if
we
could
have
some
level
of
consistency
across
various
languages
or
across
the
SDKs?
Do
you
think
that's
a
pipe
dream
and
again
it
actually
can't
be
done,
because
there
are
so
many
differences
and-
and
you
want
things
to
look
more
native
and
so
trying
consistency
is
actually
going
to
hurt
that
I
I.
D
D
A
D
Don't
know
exactly
I
think
he's
he's
assuming
like
some
very
big
structure
around
factories
and
conversions
and
marshaling,
and
so
the
you
always
get
a
valid
event,
but
I
don't
understand
how
you
would
assemble
an
event
cuz
like
as
you're
assembling
it.
You
either
need
to
make
a
Builder
pattern
and
if
the
final
thing
you
say
build
and
you
get
a
valid
event
and
you're
only
interacting
with
the
Builder,
but
that's
not
how
go
works.
Mm-Hm.
A
Like
I
need
anything,
I
can
reread
the
duck
yeah.
Okay,
it's
interesting,
but
it
sounds
like
a
good
topic
for
us
to
have
on
the
next
call
with
Cliff
Clemens
on
so
okay,
but
we
actually
only
have
four
minutes
left
on
this
call
and
I
wanted
to
come
on.
Do
all
the
touch
on
your
on
your
subject
Scott,
he
said
responses
to
events.
What
do
you
want
to
talk
about
there
so.
D
He
he's
trying
to
push
down
some
very
big
changes
in
the
going
SDK
to
make
it
kind
of
unidirectional
by
default.
Okay,
sorry,
okay.
Let
me
step
back
his
general
concern.
Is
that
there's
been
some
misunderstanding
about
the
the
cloud
events
SDK
in
in
regards
to
an
event
shows
up,
and
it
is
expected
potentially
that
you
can
have
a
response.
So
this
is
very
true
in
HTTP
and
it's
actually
very
useful
property
because
you
don't
need
to
have
any
you
don't
have
to
have
the
next
stage
wired
up.
D
You
can
have
an
invoker
that
goes
and
invokes
a
function
with
a
cloud
event
and
that
produces
a
new
event.
Potentially,
it
doesn't
have
to
be
as
like
as
a
response
to
that
event.
In
the
terms
of
the
sender
of
the
original
event
intends
to
receive
this
response.
It's
more
we
in
so
in
Canada.
We
use
this
mechanism
to
do
filtering
so
if
an
event
goes
in
to
a
function,
the
function
that
can
act
as
a
filter.
The
response
then
gets
forwarded
on
to
the
next
stage.
D
If
there
is
one
and
if
there
isn't
one
that
event
chain
gets
filtered
out
or
that
filter
has
the
chance
to
mutate
that
event
or
potentially
make
multiple
events,
but
this
is
only
a
feature
of
H
DDP
and
so
there's
probably
some
guidance
required
from
the
cloud
events
SDK.
Sorry,
the
cloud
events
spec
to
talk
about.
D
E
E
D
I
have
a
client,
and
it
some
transports
support
this
mechanism
of
having
a
response
in
some.
Don't
so
I
made
the
choice
that
the
top-level
interface
has
this
optional
piece
you
can,
you
can
say,
I,
accept
responses
and
I
or
I
produce
responses
most
of
the
transports
in
the
golang
SDK
ignore
this
field,
because
it's
not
actually
supported
by
that
transport.
E
Well,
I
think
it
becomes
a
patent
issue
because
now
I
mean
you
know
much
as
Scott
might
want
to
disregard
it.
Clemens
is
SDK
document
I,
that's
the
sort
of
stuff
that
would
go
in
there
yeah.
It
would
define
the
expected
contracts
so
Scott.
It
sounds
like
you're,
saying:
okay,
Adam
Marshall,
something
off
the
wire
I.
Give
it
to
somebody
to
do
something
with,
but
is
it
my
job
to
send
the
response
back
or
is
it
somebody
else's
job.
A
E
So
Scott
I
I
see
your
point,
but
the
way
I
sort
of
and
I
said,
I'd
not
spend
a
lot
of
time
with
yesterday's
yep
I'd
sort
of
viewed
them
as
they
would
be
rapid
by
something
else.
Yeah
so
I,
don't
know,
I'd
have
a
jax-rs
end
point,
no,
no
I
would
code
and
it
would
go.
Oh
I've
hit
the
same
point.
Therefore
I'm
gonna
use
this
SDK
function
to
D
Marshall,
my
HTTP
requests,
rather
than
it
rather
than
expecting
the
SDK
to
actually
own
that
jax-rs
or
the
actual
endpoint
protocol.
E
M
C
There
isn't
a
single
for
nodejs.
Specifically
there
isn't
a
single
format
for
HTTP
requests.
You
could
get
the
SDK.
If
it
doesn't
own
the
client,
then
it
doesn't
know
the
format
of
the
headers.
For
example
right
you,
then
you
would
have
to
have
separate
separate
marshallers
for
different
HTTP
clients
and
stuff,
and
the
data
conserve
I
think,
but.
E
Are
you
gonna
have
that
problem
anyway?
I
mean
this?
Is
the
the
double-edged
sword?
Would
sdks
yeah
I
mean
that
I
don't
know?
We
as
a
company
may
have
said
no
we're
not
allowed
to
use
that
particular
constructs
for
those
under
ability
purposes
or
whatever,
yet
the
SDK
actually
uses
those
I
needs
is
tricky.
Yeah
I
mean
I,
don't
know
that
there's
any
way
around
that,
but
it's
a
good
point.
You
run
into
dependency
problems
where
you're
sort
of
the
the
low-level
SDKs
assigned
to
drag
in
you
know
other
dependent,
libraries,
yeah.
E
So
maybe
this
is
a
bigger
question
and
you
know,
as
an
sdk
writer,
am
I
required
to
be
unup
enya
nated
and
make
it
more
complicated
so
that
people
can
plug
in
their
own
bindings
or
whatever
or
am
I
allowed
to
be
extremely
opinionated
and
say
nope.
This
is
the
way
that
the
eye
marshal
stuff-
and
you
know
it's
on
me-
I.
C
You
know
doing
the
transport
yourself
because
of
exactly
those,
for
example,
company
policy
issues
that
you
might
not
be
able
to
affect
in
any
way
yeah,
and
that's
also
something
that's
got
talked
about,
so
I
mean
both
are
better,
but
for
someone
just
doing
a
random
crowd
event
supporting
us,
they
care
of
it
makes
sense
to
require
both
they
can
do
and
call
me
up
any
edits.
Yeah,
look
just
no
reason
in
my
opinion
to
make
me.
D
C
Now
I
actually
have
a
similar
thing
for,
after
that
came
to
existence
before
cloud
events
in
our
company
that
will
be
ported
to
cloud
events
and
supporting
multiple
transports
once
the
expect
is
1.0
and
I
do
think.
That's
actually
an
approach,
but
I
also
think
like
it
would
be
pretty
weird
not
to
have
a
if
it's
considered
an
official
SDK
to
not
have
a
more
low
leave
a
low-level
codec
endpoint
that
you
were
talking
about.
Yeah.
L
D
C
K
C
That's
fine
I
was
just
like
now
at
the
there
is
DPR
for
architecture
section
on
the
primary
and
it
like
I
was
actually
thinking
more
on
those
lines.
You
know
having
a
separate,
JSON,
codec
and
the
transport
marshal.
Then
you
don't
need
to
have
15
different
JSON
codecs,
just
one
one
15
different
transport
level
right.