►
From YouTube: CNCF Serverless WG Meeting - 2018-07-19
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
I
can
now
good.
Thank
you
all
right.
Three
up
today,
oh
I,
don't
go
and
get
started,
look
into
the
eyes.
I,
don't
think!
There's
anything
worth!
Oh
wait
a
minute!
No,
no!
Nothing
is
anything
worth
bringing
up
well
to
the
a
I
say
other
than
if
you
have
one
please
get
to
it.
When
you
get
a
chance
where
you
can
assure
screen,
oh
I
thought
I
was
yeah.
Yes,
oh.
B
Cool
good
I
said
a
little
green
box
around
it.
I'm
not
worried
there
for
a
minute,
all
right,
all
right
community
time.
Is
there
anybody
from
the
community
who
isn't
part
of
the
knurl
working
group?
Who
would
like
to
bring
up
a
topic
for
discussion,
whether
it's
an
issue
or
question
or
concern,
or
anything
like
that.
D
B
D
E
I've
got
a
few
of
them
and
they're
all
making
data
in
the
basic
JSON
format,
so
I'm
trying
to
think
about
how
to
now
get
that
into
a
cloud
event,
and
it
could
just
be
building
up
the
JSON
on
the
device
sending
it
over
mqtt
or
similar
I'm,
hoping
to
get
a
blog
posts
together
with
it
as
well,
and
show
how
you
can
then
start
ingesting
it
for
a
function
core?
Is
there
something
that
you
know
wondering
if
M,
if
clapping
events
is
a
bit
too
heavy,
wait
for
sensor
readings?
E
C
F
C
Way,
I
would
answer.
That
is
that
for
for
those
use
cases
where
it
makes
sense,
you
can
use
it
that
way
and
there's
always
been
the
the
concept
of
taking
a
different
event
format
and
translating
that
through
middleware
into
a
cloud
event
for
later
transmission.
So
if
your
device
is
small,
you
can
still
use
your
existing
way
of
sending
events
out.
You
just
said
you
would
just
translated
on
another
layer,
yeah.
E
E
B
E
B
So
it
sounds
like
you
may
have
some
feedback
for
us
once
you
get
the
the
full
thing
up
and
running
and
give
us
feedback
in
terms
of
whether
there's
something
wrong
with
the
spec
or
it
works.
Okay,
or
something
like
that
right,
yeah,
maybe
I'm
hoping
say:
okay,
yes,
I
think
it'd
be
useful.
Then,
especially,
if
you
do
think,
if
you
do
find
issues
with
the
spec
itself,
then
I
think
opening
up
issues
or
a
pull
request
to
actually
make
changes
to
make
it
better.
G
The
effort
so
far
has
appeared
to
relate
to
transitory
transmission
of
events,
and
one
of
the
the
use
cases
that
we
find
ourselves
very
interested
in
in
my
team
is
the
kind
of
events
or
store
the
commit
log
as
the
source
of
truth,
and
that
the
there
seems
to
be
a
sorry
and
I'd.
This
I
didn't
prepare
these
statements.
G
B
No
one
so,
from
my
point
of
view,
I
tend
to
look
at
the
cloud
event
spec
as
more
as
a
this
is
my
phrase
for
more
of
a
transport
mechanism
of
transport.
Encoding
put
it
that
way
and
what
happens
to
it
on
either
side
of
that
transport
is
sort
of
out
of
scope
for
us.
So
the
question
of
the
persistence
of
a
cloud
event
beyond
it
being
delivered
to
April
it
to
a
consumer.
F
D
F
G
There
does
seem
to
be
the
general
assumption,
so
so
let
me
be
a
provide
a
concrete
used
case.
The
the
log
that's
being
built
up
of
events
written
to
it
would
contain
something
like
bounced
updates
and
it
would
be
appropriate
for
me
to
enter
an
event
onto
the
log
that
transferred
money
from
my
account
to
another
account.
G
However,
it
would
be
inappropriate
for
Doug
to
enter
that
same
event
onto
the
log
and
without
the
context
of
the
active
connection,
then
there
there
would
be
without
some
sort
of
extra
information
and
that's
sort
of
like
it
going
the
the
kind
of
payload
data
section
of
the
event,
if
didn't,
if
needed,
so
bear
with
me,
I'm
just
trying
to
bring
this
up
as
an
interesting
thought
exercise,
but
there'd
be
no
way
to
using
the
plan.
Event
spec
ensure
that
that
event
was
produced
by
so
many
authorized
to
do
so.
B
It
seems
like
that
this
might
be
worth
just
opening
up
an
issue,
so
people
can
think
about
it
offline
and
and
put
comments
in
there.
We
can
all
have
discussion
in
that
one
spot
I
mean
even
if
it
ends
up
deciding
not
to
do
anything
with
it.
I
still
think
it
might
be
useful
just
to
document
it
someplace
to
show
that
we
actually
thought
about
it,
and
we
decided
to
do
one
thing
or
another
with
it.
Based
upon
that
discussion
and
people
can
sort
of
see
the
history
of
it
good.
Thank
you.
B
B
B
H
H
E
H
When
thinking
about
open
source
projects
and
branding
them,
the
first
thing
that
comes
to
mind
is
a
graphic
on
the
top
of
the
readme
and
I
always
start
there.
That
is,
that
is
where
you
communicate
the
developers
like,
first
and
foremost
these
days,
so
that's
kind
of
what
I
had
in
mind
as
I
as
I
designed
this
thing
and
I
just
threw
in
a
tagline.
It's
not
the
tagline
I,
don't
know
if
we
really
have
a
set
tagline
but
yeah.
That's
the
context
which
I
imagined
while
I
was
designing.
This
okay.
B
B
B
All
right
cool
anything
else
related
to
logos.
Once
the
new
one
is
ready.
I
can
start
ordering
stickers.
I
had
to
get
a
coupon
code
from
Dan
Khan,
so
I
can
order
a
whole
bunch
of
stickers
through
the
store
for
free.
But
then
you
should
be
able
to
order
your
own
stuff
through
there.
Unfortunately,
they
don't
have
t-shirts
available
through
the
CNCs
store.
So
if
you
want
to
do
t-shirts
have
to
go
someplace
else,
whether
we
do
it
at
the
group
or
individual
companies
want
to
do
it.
That's
up
to
us
to
decide
I.
B
B
H
I'll
do
a
quick
recap:
there
are
a
few
of
us
who
are
working
on
cloud
events
SDKs
for
cloud
events.
We
have
a
few
implementations
in
the
works,
javascript
go
and
java
and
someone
was
doing
a
python
one,
but
they
were
not
the
last.
They
were
not
the
last
couple
meetings
so
anyway,
we're
cruising
along.
We
have
our
roadmap
laid
out
in
the
cloud
events,
design
proposal
document
and
what
we
did
it
during
the
last
sync
meeting.
H
Is
we
shared
our
progress
and
we
shared
kind
of
pain
points
where
we
need
additional
clarity
and
our
learnings?
We
have
a
couple
things
that
we
kind
of
need.
Some
we
still
need
to
figure
out.
The
first
is
how
to
design
the
sdk
in
a
way
that
it
can
accommodate
this
spec
as
it
evolves.
You
know
if
we're
gonna
be
building
kind
of
api's.
H
You
know
getters
setters
on
cloud
events
in
the
sdk
experience.
How
is
that
going
to
be
affected
when
the
specification
evolves?
So
that's
something
we're
still
trying
to
figure
out
and
also
we
realize
that
there's
a
bit
of
a
challenge
in
how
we
handle
all
that
evolution
also
with
the
transport
and
binding
specifications
and
how
those
are
going
to
be
evolved,
because
if
the
cloud
event
spec
is
changing
and
the
transport
the
binding
specs
are
also
changing
and
we're
trying
to
build
the
SDKs
around
this.
H
In
addition
to
just
being
custom
properties
on
the
cloud
events
envelope
should
be
an
experience,
that's
kind
of
carried
through
into
the
SDKs,
and
we,
you
know,
we
kind
of
pioneered
this
idea
of
almost
like
middleware
or
extra
modules
of
code,
that
you
could
add
to
the
SDK
that
would
kind
of
extend
the
ability
of
the
SDK
in
what
it
what
you
can
do
with
it.
So
good
couple
examples
are
you
know?
H
Maybe
if
someone
is
making
a
middleware
products,
they
could
add
in
you
know
their
extension
for
that
middleware
product
into
the
SDK,
and
if
the
SDK
has
a
published
method,
it
would
use
that
specific
middleware
to
send
out
the
event,
as
well
as
put
custom
attributes
in
the
extensions
area
or
as
extensions
on
the
cloud
events
envelope.
So
we
wanted
to
think
about
that
experience.
Kind
of
you
know
not
just
as
custom
data
anymore,
but
also
code
and
logic
that
you
can
add
into
the
SDK
and
I.
H
Think
if
we
do
that,
and
we
think
about
that
first
well,
we're
just
architecting
the
SDK
that
is
going
to
set
this
effort
up
for
success,
because
that
is
a
great
place
for
vendors
for
the
community
to
add,
to
build,
write,
custom
code
to
extend
this
and
do
more
with
cloud
events.
It's
a
great
place
for
companies
and
teams
to
bacon-like
to
write
their
own
extensions
to
ensure
that
whoever
is
doing
this
adventure
and
development
with
cloud
events
can
follow
standard
kind
of
organizational
policies.
H
A
H
I,
don't
know
for
a
position
to
say
this:
I
mean
we're
gonna
we're
gonna,
we're
gonna
make
SDKs
for
cloud
events.
It
sounds
like
we're
also
going
to
put
them
in
the
cloud
events
org
on
github
and
they
will
be
SDKs
for
cloud
events
and
I.
Think
they've,
given
that
they'll
be
there,
they'll
have
a
lot
of
communities
port,
but
no
way
does
that
prohibit
anyone
from
making
their
own
their
own
SDKs
and
their
own
custom
things.
Additionally,
that
it's
the
extensions
story.
H
If
we
get
this
right,
you
should
be
a
great
way
for
you
to
really
customize
it
to
do
all
types
of
things.
If
that's
of
interest
to
you
so
I
feel
free
to
always
write
your
own
code
and
stuff
we're
just
kind
of
working
on
this
stuff
together
to
come
out
with
a
similar
implementation
across
different
languages.
So
you
know
developers
have
a
easy
experience.
I'd.
C
B
Yeah
and
one
thing
I
awesome
to
talk
about
this
just
to
hammer
the
point
home,
and
one
thing
we
tried
to
talk
about
yesterday-
was
obviously
we're.
Gonna
have
different
SDKs
for
each
language
and
we
wanted
to
make
sure
that
there
was
some
consistency
across
the
various
language
SDKs,
so
that,
even
though
the
the
exact
mechanism
by
which
you
may
do
certain
actions
within
each
language
could
look
radically
different
based
upon
the
language
constructs,
because
you
wanted
to
feel
natural
to
that
language.
B
The
overall
feature
or
semantics
of
what
you're
trying
to
do
should
be
consistent
across
all
the
SDKs.
If
possible,
that
way
matter
what
language
you're
working
on,
you
should
be
able
to
do
the
same
type
of
action
and
get
the
same
net
result
on
the
wire,
for
example
having.
But
having
said
that,
from
my
point
of
view,
well,
I
agree
with
what
Austin
said:
anybody
is
obviously
free
to
write
their
own
SDK.
If
has
an
example,
there
is
already
a
go
SDK
sort
of
that
the
group
is
kind
of
working
on
it'd
be
really
great.
B
If
someone
who
wanted
to
do
it
wanted
to
work
on
a
go,
SDK
tried
their
best
to
work
with
that
current
one
if
they
could
right,
but
for
some
reason
they
found
that
they
had
to
fork
it
or
gonna
put
their
own
way.
Obviously
they
can't
choose
to,
but
as
a
community
it'd
be
great,
if
we
could
sort
of
rally
around
you
know
what
we're
producing
here
and
that
had
a
whole
bunch
of
different
versions
for
the
same
language.
H
H
Looking
for
in
the
use
cases
that
you
want
to
accommodate,
let
us
know
and
there's
a
lot
of
ways
you
could
use
this
I
mean
you
know
either
building
an
extension,
a
custom
extension
for
the
SDK
or,
of
course,
wrapping
the
SDK
with
you
know,
with
your
own
SDK
or
something
else,
I
think
over
time.
This
thing
will
provide
a
lot
of
value
and
it's
not
just
about
kind
of
instantiating
events
or
transporting
them.
It's
it's
also
about
validating
them.
It's
also
about
kind
of
testing
them
all
that
stuff.
So
you
know
I
think
this.
H
If
we
work
on
this
together
and
we
could
collaborate
as
much
as
possible,
we
could.
We
could
really
create
something
something
great
that
will
facilitate
event-driven
design,
which
I
think
a
lot
of
people
need
in
general.
That's
it
other
than
Doug
is
going
to
create
a
repo
and
we're
gonna
start
pushing
our
work
in
there.
It's
not
final
by
any
means
we're
just
kind
of
putting
it
all
in
the
same
place.
So
we
could
have
a
centralized
discussion
and,
as
we
you
know,
approach
the
first
version
here
then
we'll
figure
out.
H
I
I
haven't
gone
through
this
SDK
designed
out
yet,
but
just
a
quick
question:
does
it
include
a
section
on
the
functionality
of
that
will
be
covered
by
the
SDK,
like
what
kind
of
I
mean
features
will
become?
Yes,.
H
Kathy,
absolutely
there
are
initiatives.
We
started
off
with
drafting
initiatives,
all
the
things
that
we
thought
the
SDK
should
do.
We
stack
rank
them
prioritize
them,
and
then
we
filtered
them
into
basically
a
little
roadmap.
That's
organized
around
SDK
versions,
so
the
initiatives
are
all
the
things
that
we
want.
The
SDK
to
do
and
the
milestones
and
scope
is
basically
our
roadmap
and
what
we're
focused
on
in
the
initial
version
and
then
the
next
version
and
the
version
after
that.
H
I
Is
there
like,
okay,
see
here
these
okay,
just
a
quick
question,
a
different
API
is:
is
there
like
API
to
expose
on
the
the
metadata
defined
in
the
uncrowned
events,
yeah.
H
That's
it's
a
very
loose
description
of
that,
so
I
apologize
for
that
I
think
we've
kind
of
converged
on
a
few
ideas
as
to
what
that
looks,
like
I'd,
say
to
get
more
info
about
that.
Just
look
out
for
the
cloud
events,
repo
cuz,
we're
gonna
start
pushing
our
implementations
there
and
you'll
see
kind
of
some
of
the
api's
that
were
that
were
focused
on
initially
okay.
F
F
B
I
So
we
in
last
meeting
we
went
through
some
existing
offerings
for
the
work
flow,
wise
function
graph,
the
other
is
open
risk
and
yeah.
We
have
a
discussion
on
that
and
then
we
went
also
went
through
review
comments
and
on
the
work
flow
proposal,
document
document
and
so
I
think
we
agree
that
we're
going
to
post
more
comments
and
poke
holes
at
the
attach
that
draft
in
the
next
meeting,
we're
going
to
you
know,
go
through
all
the
review
comments
and
then
discuss
it.
A
reach
consensus,
yeah
all
right.
Any
questions
for
Kathy.
B
Okay,
just
a
shout
out
the
the
proposal
document
Kathy
has
I
know
there
have
been
some
comments
made
in
there,
but
I
think
it
might
be
good
to
have
more
feedback.
So
if
you
guys
get
a
chance,
please
do
take
a
look
at
that
document
and
provide
feedback
then
help
the
workgroup
alright
before
we
move
forward
any
other.
Any
last
questions
comments
for
Kathy,
all
right,
cool
I,
don't
pay
the
same
issue,
maintenance
issues.
You
need
to
work
with
right
now,
so
we
can
jump
into
PR
stuff.
B
So,
let's
see
now,
last
week's
call
Clemens
talked
about
this
qualifying
protocol
is
an
encoding
document
and
we
talked
about
how
this
document
was
basically
going
to
define
the
bar
that
we
were
going
to
follow
or
use
to
measure
whether
we
adopt
a
encoding
or
transport
binding
specification
into
our
workgroup,
and
some
people
were
supposed
to
go
off
review.
This
make
sure
they
were
okay
with
the
bar
that
he
was
defining
here.
I
believe
the
only
comments
in
here
I
had
couple
of
words,
smithy
kind
of
things
we
can
ignore
those.
B
B
J
Yeah
just
cuz
I
remember
last
time
we
were
talking
about
Clemens
good,
make
it
a
list
so
that
it
would
be
more
less
subjective.
We
can
go
through
the
list
and
clearly
say
if
it
is
meatball
or
not
I'm,
not
bad.
If
I
ever
met.
Remember
correctly,
that's
what
he
is
supposed
to
do,
but
I'm
not
sure
I
see
clearly
a
list.
J
J
Is
defined
a
fashion
that
allows
alternative
implementations,
it
seems
to
me
that
this
is
pretty
loose
like
what
is
allowed
it's
not
allowed
when
he
was
talking
about.
He
was
a
little
bit
feels
to
me
like
he
was
a
little
bit
more
concrete
like
he
said.
Something
like
it
needs
to
be
implemented
by
two
different
organizations,
something
like
that.
Yeah.
B
J
B
I
mean
you
are
correct:
he
does
keep
it
kind
of
loose
there.
Is
this
difficult
cuz?
Obviously,
Clements
is
not
on
the
colleagues
on
vacation,
but
I
know
you're
right.
He
does
not
have
a
formal
sort
of
bulleted
list
of
things.
I
believe
these
two
paragraphs
would
probably
be
the
closest
thing
to
his
bulleted
list
right.
B
If,
if,
if
you'd
like
to
see
a
little
bit
more
specificity
around
what
the
criteria
is-
and
it's
basically
like
a
bulleted
list,
it
says
these
three
things
must
be
met
right
and
concrete
terms,
number
of
implications.
That
kind
of
stuff.
Could
you
add
another
comments
with
concrete
proposal
for
text
that
you'd
like
to
see
in
there
that
way,
we
can
all
look
at
it
and
consider
it
sure.
B
Example,
I
don't
know,
I
mean.
Obviously
we
like
to
get
this
issue
resolved
at
some
point,
but
I
don't
know
if
we're
necessarily
in
a
hurry,
we
can
do
it
immediately
other
than
there
are
two
other
PRS
that
are
kind
of
blocked.
On
this.
You
know
new
specifications,
but
I
know
those
owners,
probably
wanna,
get
it
resolved
soon,
but
I
don't
think.
As
a
working
group.
We
have
to
get
this
resolved
today,
so
I
think
it's
fair
for
you
to
take
some
time
to
figure
out.
B
B
K
This
is
Colin,
hey,
yeah
I
just
wanted
to
echo
Ryan's
concerns
as
well.
You
know,
I
have
some
of
the
same
concerns
and
then
you
know
also
if
there
are
gonna,
be
you
know,
let's
say
blessed
transports.
Is
there
gonna
be
an
option
for
other
transports
to
get
in
as
well
just
to
to
allow
more
people
to
integrate
and
perhaps
add
their
own
bindings
in
the
cloud
events.
B
B
F
B
B
B
B
B
B
F
B
J
B
Yes,
because
the
last
thing
I
want
to
do
is
have
people
think
that
we're
we're
either
playing
games
or
doing
some
sort
of
politics
around
who
we
let
in
and
who
we
don't.
Do
we
not
on
make
sure
we
have
consistent
rules
that
we
follow
yep
yeah,
exactly
yep,
totally
agree
yeah.
So
if
you
could
just
show
the
exact
text
you
want
to
see
in
there
that
way
again,
there's
no
ambiguity.
I'm
voting
on
then
I
can.
If
we
agree
to
it,
I
could
always
just
do
a
copy
and
paste
an
update
is
PR.
Yes,.
J
J
B
All
right
cool,
thank
you
guys,
all
right
in
that
case
we'll
skip
the
next
two
PRS
since
they're
based
or
they're
gated
on
Clemens
PR.
So
next
up
is
Cathy.
Would
you
like
to
discuss
your
PR
that
has
now
been
renamed
to
add
a
properties
or
rename
it
to
properties
or
I'm?
Sorry,
add
properties
attributes
like
to
talk
to
this
one
and
since
there
been
some
changes,
yeah.
I
Okay,
so
basically
so
this
is
about
so
we
all
don't
have
a
purpose
that
you
know
for
the
for
the
event
producer.
To
put
you
know
it
sure
information,
you
know
he
think
it's
needed
on
to
this
properties.
I
I
mean
the
contents
of
the
property
will
be
key
value
pairs,
but
it
does
not.
He
not
have
any
amended
the
definition
of
the
case
and,
for
example,
a
producer
could
put
an
event
identification
label
which
will
be
used
by
the
service
platform
or
service
conceived
n
consumer
to
correlate
the
event
with
other
types
of
events
associated
with
the
same
service
application.
This
is
just
an
example.
It
could
be
used
for
other
purpose
too.
Of
course,
when
the
event
producer
add
the
new
key
by
repair,
he
should
you
know
she
should
be.
I
That's
pretty
much
about
it
and
there
in
the
extension
document.
You
know,
there's
some
defined
some
attributes
and
if
you
know
the
producer
like,
you
can
put
that
as
a
keys
in
this
inside
these
properties
I.
This
is
optional
field,
and
then
you
know
and
there's
some
there's
an
example
of
how
you
know
and
to
put
this
key
value
pair
into
these
properties.
If
you
scroll
down
doc,
yeah.
B
I
think
that
the
net
of
this
PR
and
compared
to
the
previous
versions
of
this
PR
is
that
this
is
just
renaming
the
extensions
bag
to
be
called
properties
and
to
make
it
clear
that
this
isn't
just
for
the
things
that
we've
defined
in
our
extensions
MD
file.
This
is
open
for
third-party
people,
other
vendors,
whoever
to
include
it
for
other
things,
such
as
the
correlation
stuff.
That
Kathy's
talked
about
yeah.
I
H
B
I
think
there
was
some
confusion
around
how
the
extensions
bag
was
meant
to
be
used.
In
particular,
I
think
there
was
some.
There
are
some
people
in
the
group
who
thought
that
it
was
only
for
stuff
that
we
defined
in
extensions
died
md
because
they
both
shared
the
same
word,
extension
mm-hmm,
and
so
this
was
and
I
think.
This
is
an
attempt
to
clarify
that
this
really
is
for
other
things,
and
not
just
the
stuff
that
we
might
define
in
that
document.
Mm-Hmm.
H
Okay,
I
appreciate
Kathy's
effort
here,
I'm
I'm,
a
fan
of
the
extensions
word
personally.
Actually
it's
fairly
clear
property
seems
a
bit
more
confusing
to
me
because
it's
it
seems,
like
everything,
is
already
a
property
in
the
envelope
there
and
we
were
just
kind
of
rolling
out
this
nice
SDK
experience
around
this
whole
extensions
concept
and
this
this
kind
of
might
confuse
the
story
a
little
bit,
not
sure
how
everybody
thought
it
through.
But
those
are
just
my
immediate
thoughts.
L
I
think
that
really
depends
on
whether
or
not
extensions
move
to
the
top
level
or
not.
Given
that
we've
there's
been
a
lot
of
talk
about
that,
I
think
that
properties
and
extensions
would
we
would
want
to
be
able
to
delineate
between
them
in
that
scenario
and
so
that
we
could
identify
them
as
two
separate
concepts.
I.
M
Kind
of
agree
with
that
I
think
this
is
something
that
many
developers
would
want
to
use
additionally,
identifying
the
source
I
mean
it's
one
thing
to
say
extensions,
my
mind
my
take
is:
if
we
take
an
extension
that
will
be
more
like
most
developers
are
not
gonna,
implement
it
hate
when
they
dependent,
but
if
we
make
it
part
of
something
more
I
think
this
is
what
developers
values
say
you
want
to
it's
one
thing
an
event
has
come
out,
but
you
want
to
identify
more.
There
are
more
properties
related
to
that
event.
This
might
take.
L
Also
think
this
this
particular
property-
it's
a
big.
It
should
be
useful
when,
let's
say
the
data
itself
ends
up
being
binary
encoded
or
you
know,
whatever
you're
passing,
you
know
some
file
along
it
cetera.
This
is
a
this
into
being
a
great
place
for
the
producer
for
the
application
level
code
to
be
able
to
drop
additional
metadata
that
can
describe
or
or
assist
with
that
data
block.
N
B
That
might
try
to
scope
it
too
much.
One
of
the
things
back
up
so
awesome
is
is
right
right.
This
is
just
the
name
change.
What
can
go
in.
There
does
not
change
at
all,
but
I.
Think
what
you're
hearing
based
upon
people's
comments
is
that
the
word
that
we
choose
might
imply
certain
things,
certain
people.
So,
for
example,
when
you
saw
the
word
extension,
some
people
look
at
that
as
well:
I'm,
not
defining
an
extension
I'm,
just
adding
a
property,
so
obviously
I
shouldn't
put
it
in
there.
L
Like
this
direction
that
we're
we're
sort
of
heading
right
now,
which
is
if
we
were
to
refer
to
the
extensions
as
basically
extensions
to
the
top-level
specification
or
the
top-level,
your
cloud
events
wrapper,
which
is
new
properties
at
the
top
level,
and
then
this
properties
bag
is,
is
effectively.
You
know,
usable
for
dropping
pretty
much
anything
into
you
that
the
application
may
want
to
want
to
add
I.
Think
that
helps
draw
a
little
bit
of
a
clear
delineation
there.
Well.
B
O
O
B
I
I
Yeah,
so
the
the
type
is
a
map,
so
whatever
define
the
map
right,
but
I
would
like
to
say
it's
like
a
key
value.
So
there's
a
key
there
there's
a
value
there,
but
it's
because
we
cannot
predict.
You
know
how
different
producers
is
going
to.
You
know
what
kind
of
each
oh
information
event
producer
or
like
to
put
that
in
so
I.
Think
the
key
point
is
we
do
not
have
any
money,
the
definition
of
the
case
so
for
one
producer
they
can
put.
I
For
example,
you
can
put
a
location
information,
another
producer
they
can
put
like
a
priori
ID
and
maybe
for
another
event
producer.
They
could
put
a
loan
application.
You
know
ID
something
like
that,
so,
but
I
think
for
to
support.
You
know:
I'm
not
allowed
to
use
cases
and
also
other
use
is
not
just
restricted
and
to
IOT,
I
I
think
you
know
as
an
event
producer.
L
I
But
there's
a
actually
there's
a
definition
of
what
type
things
you
know,
because
it
what
maps
that
we
might
means,
because
when
you
go
up
there,
others
there
are
other
attributes
that
have
map
yeah,
which
is
different
here.
I
So
yeah
this
is
okay,
so
it's
tension
time,
it's
a
separate
document.
So
that's
why
we
do
not
call
extension
here
because
I
know
some
people
are
confused
about.
You
know
the
relation
between
this
stmd
and
this
extension
there's
no
hard.
You
know
how
to
say
binding
bay
here
just
said:
yeah
I
know.
So
that's
why
I
think.
That's
another
reason.
I
think
email
change
to
properties.
I
I
Not
like
a
super
stir
it
just
you
know.
Some
of
this
producer
would
like
to
put
on
some
attributes
defined
in
the
extension
dot.
Md
and
put
it
into
this
property
is
fine,
but
not
necessarily
so
he
has,
to
put
you
know
anything
defined
in
the
attention
that
M
be
inside
and
his
properties,
but
if
this
cost
confusion,
I
can
remove
this.
You
know
this
last
I
am
myself
also
feel
if
put
in
there.
People
might
just
think
there's
some
relationship
between
this
party
back
and
that
extension,
dot
and
II.
B
I
Yeah,
that's
how
it
is
written
and
say
you
know
it's
so
impossible,
yeah,
it's
but
there's
no
real
hard
relationship,
say:
oh
these
two
really
relate
you
can
prevent
producer
can
puts
you
know
the
key.
The
information
which
is
its
you
know
the
producers
think
a
key
to
this
events
for
supporting
their
use
cases
not
necessary.
You
know
they
need.
J
I
I
B
J
Okay,
that's
what
I
yeah!
That's
what
I
thought?
Okay
she'll
be
here
yeah,
so
that
just
seems
like
yeah,
so
they
for
the
properties
that,
in
extension,
MD
defined
should
be,
should
come
here
and
things
that
has
not
defined
as
if
the
producer
feels
like
they
want
at
something.
It
also
goes
there
right,
correct,
yeah,
okay,.
H
You
know
experiences
with
terminology
and
interprets
things
differently,
but
that
was
just
some
context.
There
I,
if
it's
just
a
name
change
properties,
tamizha
is
a
little
bit
more
confusing,
maybe
and
I
know
we're
getting
into
the
naming
naming
discussion
here,
but
I
don't
know
something
like
custom
might
be
a
little
bit
more
helpful.
I
think
that
the
name
thing
is
the
only
thing
I'm
getting
hung
up
on
and
then
of
course
like
we
just
we've
got
to
resolve
this
issue
ASAP
so
that
we
could
start
building
stuff.
H
B
So
we
are
running
a
little
low
on
time,
and
so
what,
since
this
was
just
put
in
there
yesterday,
obviously
I
think
it's
too
soon
to
take
vote
on
it
plus
of
all
the
questions.
People
have
I
think
it's
fair
to
for
this
at
least
another
week
or
so,
but
please
look
at
what
she
wrote
here.
Think
about
it.
If
you'd
like
to
see
some
changes,
please
don't
wait
for
next
week's
phone
call.
Add
a
comment
in
here:
that's
a
just
alternative
text
or
alternative
name.
You
know
it
may
be,
there's
another
name
out
there.
B
They
can
allow
that's
less
confusing
for
people
that
encompasses
both
types
of
think
return
under
here.
But
please
review
this.
When
you
get
a
chance,
we
don't
want
to
stay
silent
on
this
one.
We
want
to
get
this
one's
resolved
as
quickly
as
possible,
so
with
that
any
last
minute,
30.
Second
discussions
on
this
before
we
move
on.
B
Okay,
now
we
don't
have
time
to
do
a
deep
dive,
but
I
do
want
to
draw
people's
attention
to
an
issue
that
I
opened
up
last
night
and
this
actually,
as
a
result
of
do
you,
think
the
SDK
workgroup
call
yesterday
that
Austin
was
running.
There's
a
whole
question
about
how
we
gonna
version
our
specifications.
B
If
so,
for
example,
do
the
does
the
Jason
and
HTTP
binding
spec
stay
in
sync
version
number
wise
with
the
core
spec
right,
so
everything's,
always
at
1.0
everything's
at
1.1
or
not
so,
for
example,
if
we
end
up
changing
the
HTTP
binding
in
some
breaking
way,
but
we
didn't
actually
change
the
chorus
Peck.
What
do
we
do?
Does
the
effect
become
2.0,
but
everything
else
is
at
1.0.
Do
we
change
everything
to
be
2.0
right?
B
There's
a
lot
of
questions
here
that
need
to
be
thought
about
and
resolved
at
some
point
before
we
make
too
much
more
progress
going
forward,
or
least
before
we
read
1.0
status.
We
need
to
have
a
clear
rule
in
place
for
when
we're
going
to
version
these
specifications,
whether
they're
linked
whether
they're
separate,
but
when
all
the
time
this
I
do
a
deep
dive
here.
B
I
just
want
to
bring
up
the
issue
for
people
to
start
thinking
about
it,
and
please
comment
on
the
issue,
because
I
do
think
we
need
to
get
this
one
resolved
and
the
not
too
distant
future.
But
are
there
any
questions
about
the
concept
of
what
this
issue
is
trying
to
bring
up
that
I
can
answer
very
quickly
for
people.
B
Okay,
cool.
Thank
you
guys
very
much,
so
please
come
in
and
up
you
get
a
chance
and
I,
don't
think
we
have
time
for
any
other
deep
dive
discussion
at
some
point.
I
do
want
to
talk
about
what
are
extensions
and
what
use
cases
you
want
to
support
relative
to
extensions.
So
please
I
know
some
people
been
commenting
on
the
doc.
Thank
you
for
that
I'm.