►
From YouTube: CNCF Serverless WG - 2018-07-05
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
A
B
B
Thank
you
all
right,
let's
go
and
get
started.
Let's
see,
moving
down
skipping
over
the
AI
is
anything
too
exciting
there
to
touch
on
community
time.
So
this
reminder
a
little
bit
of
time
here
for
people
who
don't
normally
go
in
the
phone
call
for
basically
community
members
who
want
to
bring
up
topics
or
questions
or
concerns.
D
C
B
F
E
Okay,
no,
not
yet
we
yeah,
we
have
not
started
a
okay
yeah.
D
So
I'm
willing
to
have
a
have
a
play,
were
there
I've
got
an
IT
device.
I
could
start
getting
some
sensor
readings
and
seeing
how
it
works
with
cloud
events
I'm
just
not
sure
how
the
person
wrote
spec
intended
it
to
be
you,
so
maybe
I'll
ask
them
in
slack
next
time,
yeah.
G
D
D
H
G
I
D
C
D
So
I
could
try
to
format
the
message
in
the
end.
Beautiful
transport,
binding
format
on
the
device
or
I
could
try
and
send
it
to
a
broker
and
then
send
it
on
from
there.
We
expecting
that,
potentially
some
service
would
run
reading
from
the
mqtt
queue
subscribing
to
that
and
then
invoking
I
guess
invoking
the
functions.
H
Yes,
so
Kathy
probably
has
more
details
on
this,
but
we
have
also
been
worrying
with
the
IOT
case
said
that
the
broker
gateway
could
be
the
thing
that
actually
does
the
first
conversion
of
any
raw
data
to
a
cloud
event
and
that's
considered
canonical
is
an
allowed
thing.
Lobby,
hater.
Okay,
that's
a.
E
D
B
K
B
B
B
Oh
I
was
gonna
talk
about
that
when
we
got
around
to
talking
about
the
demos
and
stuff,
just
not
on
the
agenda
for
today,
but
probably
see
we
can
talk
about.
If
we
have
time
yeah,
okay,
Alex
are
back
to
your
mq
Keith
MQTT
thing.
Any
other
comments.
Questions
on
that
sounds
like
you
were
gonna.
Do
some
investigation
right.
D
B
K
Sure
you
kind
folks
gave
me
two
weeks
to
throw
out
a
few
other
logo
suggestions.
I
added
a
couple
to
this
github,
as
well
as
another
gentleman
who
came
up
with
a
kind
of
a
clever
idea
around
the
balloon.
So
I
also
took
that
and
did
a
few
a
few
riffs
on
the
balloon
concept.
So
in
there
there's
really
they're
really
only
two
concepts.
K
Those
are
there's
our
icon
as
I
kind
of
we're,
currently
that
we
currently
have
with
an
updated
font
to
look
a
little
bit
more
modern
those
are
near
the
top
and
then
there's
another
concept
with
a
balloon
that
was
inspired
by
Christophe
and
yeah.
So
there's
a
few
things
in
there.
Each
one
is
posted
as
a
separate
comment
in
that
thread.
Maybe
if
we
like
them,
we
could
just
give
them
a
thumbs
up
and
figure
out
kind
of.
What's
what
people
are
most
excited
about?
Do.
B
F
I,
like
the
thing
that
occurs
to
me,
is
that
it
might
not.
It
might
be
too
simplistic
to
just
vote
because
there's
a
lot
of
overlap
between
these
could.
So
if
we
have
like
a
three-second
conversation
about
like
I,
really
like
the
spot
and
I
really
dislike
the
blue
or
whatever
it
is,
then
could
we
like
get
to
one
really
quickly
make.
K
But
I
think
we
should
I
think
we
should
at
least
take
a
few
minutes
to
discuss
it.
See
if
there's
anything,
that's
interesting
here
or
you
know,
there
could
be
some
good
points
that
I
totally
overlooked.
So
maybe,
if
we
want
to
time
box
it
and
just
chat
about
it,
real
quick,
I'm,
totally
open
to
that.
Okay,
I.
L
D
D
So
you
could
make
this
ego
sharper
at
the
end
or
yeah
I'm
wondering
about
something
like
that.
So
do
you
really
like
the
design
or
perhaps
even
adding
a
little
bit
more
of
a
gap
breaking
the
e
from
the
rest
of
the
cloud
like
C's
broken
or
tinting,
the
C
a
little
bit?
So
you
can
see
it's
a
letter.
It's
a
very
smart
design,
very
flowing.
C
B
K
Yes,
I
thought
a
bit
actually
I
tried
to
make
it
a
different
color,
maybe
the
same
color
and
then
use
a
gradient
to
kind
of
fade
it
into
the
rest
of
the
cloud
icon.
Yeah
I
couldn't
really
nail
it
so
I
dropped
that,
but
I
could
certainly
do
another.
Take
where
I
just
add
in
some
more
spacing
around
the
C
yeah.
D
B
M
B
I
I
B
C
M
D
There
needs
to
be
probably
a
variation,
and
then
we
had
a
discussion
a
bit
a
couple
of
calls
ago
about
the
t-shirt,
idea
and
I
think
this.
This
middle
bit
would
go
really
well
on
on
a
t-shirt,
maybe
with
the
text
on
the
back,
so
be
able
to
split
the
graphics
up
into
a
few
different
assets.
When
we
finally
decide
what
we,
what
we
need
that
could
help
people
that
go
on
to
make
that
kind
of
merchandise.
B
K
I
could
separate
the
sea
I'll,
remove
the
remove
the
tagline
at
some
point.
I
think
we
should
have
a
conversation
about
that
tagline
too,
just
to
figure
out
what
what
we
think
is
best,
but
that's
a
whole
other
exercise
yep
in
the
meantime,
I'll
I'll
iterate
on
this
I
noticed
that
one
of
the
balloon
graphics
got
some
thumbs
up.
So.
B
K
B
K
B
Thanks,
thank
you
all
right,
Kathy.
Is
there
anything
you'd
like
to
mention
about
the
workflow
meeting
that
we
had
on
Tuesday?
Oh.
E
Also,
we
also
the
scope
of
functionalities
and
and
also
the
what
what
had
the
approaches
to
for
without
the
Proteas
for
specified
specifying
the
workflow
we
I
think
we
are
going
to.
We
decided
we're
going
to
add
use
cases,
a
section
of
use
cases
to
help
better
understand
the
scope
of
functionary,
hate
and
anger,
and
also
like
you
know,
maybe
you
see
what's
missing
there
and
we
also
also
going
to
have
people
present
existing
ways
of
doing
the
workflow
from
different
companies.
E
E
It
is
a
subgroup
of
the
service
or
group
I
think
it's
a
little
bit
independent
of
the
crowd
events,
although
it's
related,
so
it's
every
Tuesday
weekly
but
I'm,
not
planning
that
we
are
going
to
you
know,
drag
that
meet
that
weekly
meetings
for
a
long
time.
I
think
you
know
once
we
have
a
good
understanding
of
the
use
cases
and
scope
of
functionality,
and
then
we
draft
to
the
specification
I
think
we
are
going
to
come
back
to
this
work.
E
M
B
B
B
Who
was
it
s-sarah?
She
added
a
PR
a
while
ago
about
of
a
quote
starter
dock
and
I
realized
that
that
kind
of
overlaps
with
the
primer
stuff
that
I
did
here
so
late
last
week,
I
added
some
of
the
text
from
her
PR
into
here,
because
I
thought
it
would
be
good
to
try
to
merge
the
two.
So
hopefully,
if
people
like
this
general
direction,
they
will
close
off
that
PR
as
well,
but
other
than
that
there
haven't
been
any
changes
to
it
since
the
last
week.
B
F
B
F
B
They
were
there
I,
just
oh
I,
guess
I
should
point
out.
I
did
call
them
rather
than
use
cases
I
call
it
value
proposition
because
they
didn't
seem
like
use
cases
to
me
as
much
as
they're,
trying
to
explain
why
cloud
events
would
help
in
certain
cases
that
people
are
bothered
by
the
word
or
the
phrase
value
proposition.
I
know
Paula,
switching
back
to
use
cases.
It
just
seemed
more
appropriate
to
call
it
this,
but
it's
a
minor
tweak
I,
don't
care
either
way,
but
the
text
itself
is
still
there
cool.
A
H
All
right,
the
one
thing
that
I
was
hoping
to
see
that
I
didn't
was
not
just
design
like
scope,
known
goals,
but
just
things
that
we've
realized
are
anti
patterns
like
the
embedding
of
a
topic
or
destination
into
the
event.
Is
that
separate
PR
or
is
that
position.
B
No,
this
is
definitely
just
a
starter.
Pr
I
was
hoping
that
people
would
I
would
notice
things
exactly
like
that
that
are
missing
there'll,
be
great
topics
to
add
that
to
that,
but
we
do
that
as
follow-on
PRS.
This
is
just
to
get
something
out
there,
people
to
start
poking
holes
at
okay,
I'll
save
it
for
a
future,
and
then
okay,
great,
thank
you,
but
that
definitely
is
a
great
topic
dad,
yes,
anything
that
would
it
would
explain
to
people
who
weren't
part
regular
calls.
B
B
B
So
in
this
PR,
if
I
marry
correctly,
what
he
was
doing
was
for
the
most
part,
adding
text
down
here
that
basically
talked
about
how
extensions,
don't
necessarily
have
to
follow
the
same
pattern
that
we've
laid
out
for
how
they
appear
when
they're
civilized.
That
gives
us
basically
the
outs
that
we
talked
about
at
the
face-to-face
meeting.
I.
Think
that's
the
bulk
of
the
change.
Just
a
little
check
here,
I.
B
B
Zizi
penser
made
a
comment
about.
Do
we
need
to
talk
about
HTTP
headers
and
what
do
they
know?
Where
do
with
them?
You
know:
do
they
forward
them
on
they
only
forward
on
some
and
stuff,
like
that
and
Clements
came
back
and
talked
about
how
this
is
really
an
HTTP
thing
and
basically
HTTP
says
you
have
to
forward
everything
on.
B
However,
he
did
agree
that
we
should
be
clear
about
that
in
the
spec
and
I
think
that
would
be
a
good
follow
on
PR,
because
I
think
that's
true,
regardless
of
whether
this
PR
exists
or
not
so
I
think
it
would
be
a
good
thing
to
write
it
down
in
general,
so
I
think
we
could
follow.
He
could
address
that
in
a
follow
on
pull
request.
B
B
D
B
B
Obviously
it's
allowed
yeah,
but
is
it
but
it
is
discouraged,
I
carry
the
RFC
or
I.
Am
I
IETF
whatever?
It
is
a
paper
on
down
at
them,
I
think
with
Mark
Nottingham
Road,
but
I
think
that's
the
reason
that
that
Clements
dropped
the
X
was
because
they
CP
was
pretty
much
dropping
it
as
well,
but
but
this
lot,
but
the
centers
right
here
basically
allows
an
extension
to
add
it
if
they
really
want
it
to.
D
B
H
H
D
D
P
Yes,
so
that
was
my
action
item
after
I
presented
this
issue
and
at
the
face-to-face
meeting,
so
I
was
dialed
in
and
I
think.
The
conclusion
of
the
face-to-face
meeting
was
that
we
can
remove
the
event
type
version
which
I
did
and
addition
I
just
added
a
sentence
to
the
description
of
the
schema
URL
that
if
the
schema
changes
then
also
the
schema
URL
should
be
a
new
one.
O
P
O
B
All
right
cool-
you
guys
are
very
quiet
today,
alright,
well
I
wanna,
just
take
a
minute
because
I
had
a
car
I
had
a
couple
conversations
offline
with
some
people
about
extensions,
obviously
related
to
the
next
two
pr's
I'm
gonna,
discuss
and
I
just
wanted
to
get
or
have
a
brief
discussion
to
see
if
everybody's
on
the
same
page
relative
to
extensions,
because
I'm
not
sure
everybody
is
and
I
want
to
make
sure
we
all
have
a
common
understanding,
because
if
we
don't
have
to
come
an
understanding,
then
I
think
we're
gonna
continue
to
go
around
in
circles
for
a
while,
and
so
I
like
to
just
take
five
minutes
to
preview
talk
about
them.
B
If
that's
okay,
the
first
is
I
wanted
to
make
sure
that
people
understand
that
when
we
talk
about
what
is
an
extension
in
my
own
words,
basically,
an
extension
is
anything
that
is
not
specified
in
our
spec
dot.
Md
file.
Okay,
if
it's
not
in
that
specification
or
I
guess,
I
should
say:
if
it's
not
specified
in
one
of
our
formal
specifications
like
spec
MD,
then
it
is
a
than
it
is
an
extension.
B
So,
for
example,
the
extensions
that
MD
file
that
we
have
obviously
those
defined
extensions,
but
if
a
vendor
like
say
IBM,
decides
to
add
a
particular
attribute
someplace
inside
the
cloud
event.
That
is
also
an
extension.
It's
a
vendor
extension,
but
nevertheless
it
is
still
just
an
extension.
So
anything
that
is
not
defined
and
agreed
to
by
our
working
group
as
part
of
our
formal
specs
is
an
extension.
Is
that
he's
consistent
with
everybody
else's
of
you.
B
Yep,
okay,
cool
just
wanna,
make
sure
now
the
second
point
is
location
does
not
matter,
and
by
that
I
mean.
If
you
look
at
this
example
here
on
the
screen,
you
have
a
chunk
of
JSON
and
you
have
two
chunks
of.
We
have
two
properties
here
in
red.
His
apartment,
then,
is
married.
Now
not
in
the
past
or
sorry
in
our
spec.
We
talk
about
extensions.
B
We
haven't
been
a
bag
as
of
right
now
called
extensions,
so
I
think
there
might
have
been
some
confusion
about
well
what
if
things
appear
other
places
like,
for
example,
outside
that
bag
and
I,
want
to
point
out
here
that
again,
it
was
not
specified
as
part
of
our
spec.
It's
an
extension
and
that's
true,
regardless
of
where
it
appears
so
in
this
particular
chunk
of
Jason.
If
the
spec
defines
this
schema
here,
then
his
apartment
and
is
married
are
both
extensions.
In
other
words,
location
of
the
extension
does
not
matter.
They
are
still
extensions.
F
B
This
just
doesn't
talk
about
whether
we
want
to
allow
extensions
everywhere.
This
is
just
saying,
if
you
don't
say
otherwise,
and
they
are
allowed,
they
are
both
of
these
things
are
called
extensions.
It's
my
point
here
is
that
there
isn't
a
different
word
for
his
apartment
versus
is
married.
They
are
both
extensions
is
my
point.
Okay,.
B
B
E
Yeah
I'm
thinking
you
know,
so
we
need
to
be
clear
on
what
what
will
be
in
the
spec
and
what
will
be
in
the
extension.
E
So
so,
if
you
say,
like
you
know,
when
there
are
specific
things
are
in
the
extension
should
we
have
like
up
when
their
specific
spec
on
the
when
there's
extension,
like
some
extensions
back,
which
is
for
you
know,
for
when
they're
to
put
their
extension
there
I'm
I,
just
don't
think
you
know
it's
quite
right
to
just
put
any
random
things
into
the
you
know
into
the
the
events
you
know.
Anyone
just
just
can
put
anything
they
are
without
clearly
they
find
it
if
I
need.
G
All
right,
this
is
Tim,
so
the
point
about
strong,
a
strongly
typed
languages
is
a
good
one,
and
so
we've
got
a
things
kind
of
like
this
in
AWS
AWS
events
that
come
from
all
therefore
AWS
services
and
there's
a
router
and
so
on
and
there's
a
lot
of
I
mean
there's.
You
know,
there's
some
huge
number
of
services
that
he
meant
them
now
and
the
number
per
second
that's
flowing
to
the
system
is
absurdly
huge
and
that's
been
one
of
the
central
problems
we've
had.
Is
we
had
complaints
from
customers?
G
There
is
a
good
solution
because,
obviously,
at
some
point,
you're
going
to
have
a
data
field
that
actually
has
the
the
source
specific
payload
in
it,
and
you
know
unless
you
insist
that
nobody
is
allowed
to
contribute
data
unless
they
provide
a
you
know,
object,
binding
libraries
for
Java
and
go
net
and
and
so
on,
you're
kind
of
stuck
and
so
I
I'm.
Just
I'm
not
saying
that's,
not
not
a
good
idea,
I'm
just
saying
it's
a
really
hard
problem.
G
One
thing
we
did
is
so
for
the
top-level
wrapper
fields
like
we're,
really
super
fascist,
there's
only
like
six
and
they
all
have
to
be
there
always
and
no,
you
can't
ever
put
anything
else
in
there
and
so
on
and
so
forth.
So
at
least
we've
banished
the
irregularity
and
server
specific
stuff
down
to
subsidiary
elements.
I'm
not
saying
that
approach
is,
is
optimal
or
that
whether
one
the
you
know
what
events
should
take.
It's
just
some
of
our
lessons.
G
B
Again,
I
just
want
to
point
out
that,
for
the
purpose
of
this
discussion,
I
was
ignoring
the
possibility
of
of
the
specification
of
say
this
schema
banning
extensions
in
certain
spaces.
I
would
my
point
here
was
just
to
point
out
that
both
his
apartment
and
is
married,
assuming
they
are
allowed
per
the
definition
of
the
schema
that
these
are
both
called
extensions.
F
E
N
B
So
let
me
make
sure
we're
focused
on
just
what
the
one
aspect
right
keep
in
mind:
I'm,
not
focusing
on
whether
we
should
allow
extensions
at
every
spot
in
the
hierarchy.
That's
not
my
point
here.
My
point
here
is
just
to
say
that
if,
if
the
specification
allows
an
extension
at
his
apartment
level-
and
it
allows
it
to
be-
where
is
married
appears,
then
they
are
both
called
extensions.
Okay,.
F
B
Agree
and
I
the
timer,
if
I
actually
get
to
that
I,
think
I
think
that's
gonna
lead
into
the
next
PR
discussion.
My
bigger
point
here
was
just
to
make
sure
that
people
don't
think
of
extensions
that
we
define
or
send
out
different
than
vendor
extensions,
they're,
all
extensions,
and
in
particular,
whether
extensions
of
here
at
the
top
level
or
whether
they
peer
inside
a
bag
as
long
as
they're
both
allowed
they're
both
still
just
extensions.
That's
all
of
us
get
to
the.
H
Gotcha,
though
so
I
mean
in
formal
logic,
yes,
the
in
anything
that
follows
an
if
statement
where
the
condition
is
false
is
true.
However,
I
don't
think
anyone
has
proposed
there's
more
than
one
place
in
a
rendering
to
have
an
extension.
So
it's
really
hard
for
us
to
follow,
because
I
can't
call
this
an
extension
because
I
don't
all
I
see.
This
is
as
non-conforming
data
and
I
think
that
the
the
idea
that
I
disagree
with
the
premise
that
that
a
cloud
events
are
JSON
cloud
ovens
how
they
have
a
JSON
representation
and
B
I.
H
B
Agree
as
I
said,
this
isn't
getting
into
whether
we
want
to
allow
them
everywhere.
This
is
just
based
upon
a
conversations
I've
had
and
the
terminology
that
I've
heard
people
use.
People
were
putting
extensions
into
different
categories
of
extensions
and
and
in
my
mind,
we
need
clarity
on
whether
that's
something
we
want
to
propagate
going
forward,
because,
in
my
mind
an
extension
is
an
extension
is
an
extension
as
long
as
it
allowed
to
appear
there,
I
don't
care
who
created
it
or
where
it
appears.
It
is
an
extension
and
it's
not.
D
Something
else
you
carrying
some
of
his
carrying
where
it
appears,
and
that
was
because
we
were
just
looking
at
the
headers
when
we
let's
talk
about
where
it
appears
in
a
minute.
Okay,
the
other
thing
is
rachel
has
a
comment
here
that
I
don't
know
if
anyone's
spoken
about
yet
about
how
we
would
cover
this
in
a
strongly
typed
language,
yeah.
F
I
I
made
that
comment
after
I
brought
it
up
in
conversation
and
then
I,
don't
remember
it
was
it
Tim.
Tim
also
has
this
problem
I'm
not
sure,
like
I
know
Doug
that
you
want
to
isolate
the
conversation
to
what
do
we
call
this,
but
I
think
a
lot
of
our
minds
into
the
implementation
problems
that
we
see
and.
B
D
B
E
You
know
I,
don't
have
to
second
what
Thomas
just
said:
I
think
you
know
we
should
not.
You
know
allow
right,
it
will
be
confusing.
You
know
for
the
receiver.
If
you
know
anyone
a
need
of
the
producer
can
just
put
any
string
in
any
place.
Okay,.
K
B
B
Insanity,
yes,
or
in
there
yep
someplace,
basically,
yes,
okay,
so
one
last
point
before
we
jump
to
whatever
it
wants
to
talk
about,
which
is
where
do
you
want
to
allow
them
for
the
moments
give
me
some
latitude?
Please,
and
let's
say
our
specification-
does:
allow
send
an
SMS
as
a
property
at
the
top
level,
and/or
Jason,
rendering
just
give
me
that
for
a
minute
we
may
not
allow
it
I
understand.
But
for
the
moment,
let's
assume
we
do.
L
B
F
J
E
E
F
I
am
suggesting
like
this
is
my
intuition,
and
we
can
talk
about
whether
or
not
this
is
anyone
else's
intuition
and
so
say
you
have.
You
were
supporting
a
new
extension
that
includes
send
SMS
as
a
top-level
key
in
value
I'm,
not
supporting
that
extension.
I've
never
heard
of
it
before
so
when
I
get
the
event,
I
drop
that
but
I
want
to
be
as
compliant
as
possible.
So
everything
that's
in
the
extensions
like
underneath
extensions
I
will
just
pass
through.
F
B
F
F
So
for
each
so
for
each
thing,
so
for
so,
for
if
we
just
go
through
each
one
of
these
keys
and
values,
so
like
cloud
events,
version
I
know
it
to
expect
that
I
expect
it
to
be
a
string
for
source
I
expect
that
to
be
string
for
extensions
I
know,
that's
going
to
be
a
hash
right.
I
know
that
that's
going
to
be
like
we've
been
calling
a
property
bag,
but
I
have
a
clear
way
of
what
to
do
with
that
thing.
F
F
F
E
Doc
also,
logically,
group
something
together.
You
know
it
would
be
easier
for
the
receiver
to
be
Co
do
to
handle
it
rather
than
we
just
throw.
Thousands
of
you
know
could
be
hundreds
of
random.
You
know
whatever
this
s
and
I'm
SMS
or
other
things
at
the
top
level.
That
would
be.
You
know
hard
for
the
receiver.
D
I
B
So
I
I'm
fascinated
by
this
discussion
and
to
be
honest,
it
kind
of
hurts
my
head
a
little
because
all
the
arguments
for
why
this
bottom
send
SMS
is
hard
for
people.
You
should
apply
to
this
one,
and
yet
people
are
saying
it
doesn't
and
that's
mind
boggling
to
me
and
I
don't
want
to
rattle
on
this
on
the
call
here.
Cuz
I'm,
not
sure
this
is
the
best
place
for
it.
So
can
people
had
comments
about
why
these
two
are
different
into
the
PR
about
removing
the
extensions
bag
tonight,
cuz
I.
H
O
All
of
the
other
properties
top
level
properties
as
untyped
as
well
so
to
be
able
to
bind
all
this
struct
and
then
just
because
of
the
single
field
or
additional
properties
somebody
could
provide.
So
you
cannot
be
type
safe
with
the
other
stuff.
You
have
to
play
it
safe
and
use
the
like
open
key
value
net
for
everything.
Yes,.
B
E
I'd
like
to
just
add
one
more
comment
so
for
the
extension
I'm,
not
I'm,
just
thinking,
why
do
we
just
have
generic
names?
Extension
I
think
it
would
be
hard
to
have
multiple
different
categories
of
extension
right
so
that
you
can.
We
can
have
either
a
type
it
so
for
one
type
of
extension.
You
know
we
can
see,
but
we
can
give
it
whatever
the
name
right.
So
we
know
what
kind
of
type
we
want
to
use
it,
or
we
can
just
keep
it
right
instead
of
everything
into
sanity,.
F
Your
suggestion
would
be
instead
of
having
top-level,
like
does
that.
Does
that
end
up
becoming
something
analogous
to
this,
where,
instead
of
like,
send
SMS
that,
like
at
the
bottom,
that
key
would
become
something
like
this,
like
IBM
SMS
extension
like
something
like
that,
and
then
that
can
be
a
property
bag
of
whatever
it
wants.
Yes,.
E
Something
like
that,
IBM
attention-
or
you
know,
google
extension-
something
like
that
or
some
other
meaningful
extension
of
people
knows
how
to
use
it
and
also
it's
kind
of
better
to
be
defined
so
that,
of
course,
when
they're
specific
right,
you
do
not
need
offender,
it's
already
our
self-explanatory.
What's
the
what's.
L
H
Yeah
cuz
I
mean
I,
don't
necessarily
like
the
word
IBM
here,
because
one
of
the
reasons
for
extensions
is
like
something
that
you
expect
a
broader
platform
like
you
know,
if
you
look
at
our
examples,
we
have
things
for
tracing
for
sampling,
for
we've
talked
about
adding
jaw
authentication
claims.
These
are
things
that
we
excite.
We
expect
IBM
or
Google
wha-wha-what.
Whoever
will
pioneer
but
they're
explicitly
at
least
known
extensions
are
doing
it
because
they
expect
others
to
do
it.
I
agree.
B
And
that's
actually
one
of
the
reasons
why
I
want
to
remove
the
extensions
to
think
itself.
For
the
exact
same
reasons,
people
wanted
to
drop
the
X
on
HTTP
headers,
because
the
minute
they
send
SMS
becomes
a
valid
thing.
We
want
to
put
it
our
spec
if
it's
under
this
bag,
everybody's
gonna
have
to
change
their
code
to
support
it
in
two
different
places,
at
least
for
a
period
of
time.
So.
H
H
J
N
J
Had
an
extension
which
added
the
sender
Thomas
field
as
a
boolean
and
closed
event,
is
defining.
You
stand
as
a
mess
field
as
an
official
field,
and
it's
a
string
or
it's
the
phone
number
or
something
like
that
at
least,
if
they're,
all
in
the
expansion's
by
guess
with,
might
have
to
support
cheese,
but
I
won't
yet
a
new
version
of
cloud
event
conflicting
with
an
expansion
already
implemented.
B
F
I
make
one
request.
Additionally,
can
we
write
down
somewhere
what
we
like
the
format's
that
we
intend
to
support
because
I
know
from
talking
with
people
that
we
at
one
point
we
said
we
when
do
we
want
this
to
be
implementable
in,
for
example,
proto
and
JSON,
but
I'm
looking
through
the
spec
now
and
I,
don't
see
anywhere
where
that's
written
down
as
like
one
of
our
goals
like
is
there
so
like
that,
would
be
really
helpful
to
inform
these
kind
of
conversations,
I
think
yeah.
B
I
think
we've
been
kind
of
going
to
assumption
that
if
someone
wants
to
support
a
particular
protocol
or
format,
then
they
write
a
spec
for
it
and
that's
the
way
we
say
hey.
These
are
the
ones
we
support
because
they
had
there's
actually
spec
for
it.
So
I'm
expecting
some
point:
someone's
gonna
come
along
with
a
proto
one.
Is
that
not
true
Thomas.
H
B
H
Makes
it
encode
Abul,
but
it
defeats
the
entire
purpose
of
proto
and
that,
once
you
have
a
kernel
for
it,
you
have
a
library
for
it.
That
is
like
useful
and
meaningful.
If
you
then
have
to
layer
on
top
of
the
proto
based
library,
a
semantic
parsing
library
you
might
as
well
not
have
had
proto
to
begin
with
I
understood.
But
no.
The
big
thing
we're
struggling
with
is
that
proto
can't
support
a
variant
so
that
that
type
of
variable
in
our
info
site
is
incompatible
with
proto
a.