►
From YouTube: CNCF Serverless WG - 2018-08-02
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
All
right
there
we
go
three
past
the
hour.
Why
don't
I
go
and
get
started
so
today
it
was
suggested
that
we
focus
heavily
on
extensions.
It's
such
an
important
topic,
so
we're
gonna
skip
all
the
usual
administrivia
and
jump
right
into
it.
Now,
in
the
effort
or
in
effort
to
try
to
have
me
as
sort
of
moderator,
the
phone
calls
to
try
to
not
influence.
People
suggested
that
maybe
someone
else
could
drive
the
discussion
in
terms
of
the
proposal.
That's
out
there
for
extensions
and
Dan
gladly
volunteer
to
do
that.
So
Dan.
B
I
think
about
this
topic,
which
is
really
sort
of
how
do
we
see
extensions,
working
and
and
what
are
the
kind
of
the
pros
and
cons
of
that
and
I
think
this
slide
does
a
good
job
kind
of
summing
up
the
sort
of
ways
that
we
could
structure,
extensions
and
the
ways
that
they
would
look
within
our
spec
itself
and
highlight
some
of
the
pros
and
cons
of
each
approach.
I
think
the
first
bullet
is
self-explanatory.
B
It's
that
semantically
there's
no
difference
on
the
two
locations
so
that
we're
where
this
extension,
where
this
piece
of
data
is
specified,
in
this
case
a
bag
with
extensions
and
then
calm,
example,
extension
and
some
value,
or
just
at
the
root
with
some
label
and
some
value,
semantically,
there's
really
no
meaning
defined
by
either
of
those
locations.
But
then
the
next
thing
that
kind
of
drives.
B
B
B
The
first
is
that
what
these
look
like
when
they're
kind
of
flattened
out
is
that
that
extension,
piece
kind
of
takes
on
like
a
dash
sort
of
name,
so
in
this
case
C
dash
extensions,
whatever
that
extensions
name
was,
and
this
kind
of
leans
towards
the
what
was
done
with
with
HTTP,
with
the
X
dash
extensions
that
have
long
since
been
abandoned
and
that
wasn't
necessarily
a
successful
foray
down
that
sort
of
extension
path
concept.
B
Some
things
might
graduate
from
being
extensions
themselves
into
being
part
of
our
spec,
and
this
makes
a
concrete
example
of
what
that
would
look
like
is
if
some
label
was
just
an
some
some
some
extension
I
was
using
in
my
service
or
application
or
whatever,
and
then
it
becomes
we
decide.
Maybe
it's
something
location-based,
maybe
it's
something
else.
We
decided
something
important
enough
for
events
to
actually
go
in
our
specification.
Then
we
introduced
it
in
something
like
1.1
or
some
later
version
of
the
spec.
B
You
would
actually
be
breaking
code
when
you
deploy
that
if
it
was
mapped
in
the
first
way.
So
if
it's
something
that's
gone
from
extensions
in
a
path
underneath
that
to
something
that
now
as
part
of
our
spec,
like
as
we
roll
that
out,
which
is
not
going
to
be
a
clean
cut
for
any
of
us,
we're
really
gonna
kind
of
run
into
some.
B
Some
issues
about
versioning
and
part
of
my
concern
with
that
is
that,
if
version
1.1
of
our
spec
added
that
some
label,
whatever
this
extension
happens
to
be,
there
would
be
no
code
changes.
So
it
would
just
work
like
if
we
at
all.
If
people,
if
half
the
Indus,
we
had
started
using
this
same
sort
of
extension,
piece,
the
same
spec,
the
st.
where
the
same
label,
then
all
of
our
code
would
just
continue
working
even
when
we,
when
we
revved
the
spec.
B
Otherwise
we
would
have
a
breaking
change
because
now
see
e
extensions,
calm
example.
Extension
would
no
longer
be
the
name.
You
know
it
would
just
be
C
calm,
example
extension
so
that
that
kind
of
concerns
me
quite
a
bit.
I
think
this
is
a
fairly
concrete
case
of
it,
but
I
think
this
kind
of
leads
to
a
broader
discussion
of
what
exactly
we
want
to
set
us
our
goals,
both
for
the
spec
and
for
kind
of
our
future
of
this.
B
I
think
a
few
of
us
in
this
group
and
I
myself,
being
one
of
them
have
kind
of,
and
I
was
probably
the
last
one
to
make
this
journey.
I'm
have
kind
of
moved.
This
idea
that,
having
classifications
and
bags,
this
could
be
causing
more
trouble
than
it's
worth.
You
really
have
to
think
about
what
goes
into
which
bag
and,
if
we're
doing
this,
we're
kind
of
you
know
we're
really
kind
of
planning
for
a
future
that
we're
kind
of
uncertain
of
I.
B
Think
a
good
example
here
is
that
you
know
the
semantics
of
an
attribute
are
defined
by
the
spec,
not
its
location
and
the
serialization,
whereas
when
we
have
a
version
for
our
spec,
which
we
do,
we
already
know
what's
in
the
spec,
and
then
we
can
tell
that
anything.
That's
not
in
that
spec
is
is
an
extension
like
that's
already.
You
know
done
and
dusted.
It's
easy
to
do
that
with
with
the
spec
we
have
in
draft
today.
B
B
What
happens
those
things
change
over
time
or
because
of
bugs
fall
out
of
out
of
sync?
You
know,
and
we
kind
of
don't
have
a
single
source
of
source
of
truth
anymore.
So
I
think
the
proposal
here
is
to
just
say
no
classification
or
bags
at
all
that
all
extensions
are
serialized
in
the
same
way
and
that
that
kind
of
just
it's
it's
a
simple
model.
It's
not
perfect,
but
at
least
it
it
kind
of
punts
on.
C
So
I
have
a
question
here.
I
think
here
we
are
suggesting
you
know
like
so
are
we
talking
about
sterilization?
I
was
talking
about.
You
know
on
the
format
of
any
attributes,
so
I
think
we
need
to
separate
these
two
and
civilization
right
will
apply.
We
have
one
way
to
civilize
it.
It
doesn't
matter
what
can
format
the
attribute
it
is
so
that's
serialization
and
for
the
attribute
itself
looks
like
for
extension.
C
We
there
are
only
two
options:
either
we
put
everything
in
the
extension
back
or
we
put
everything
at
top
level
and
now,
of
course,
there's
a
third
option,
which
is
you
know
we
classify
the
different
different
things
into
different
classification
bags
right,
so
it's
I
think
there's
three
options.
I
can
understand.
You
know
if
we
put
everything
into
extension-
and
you
say
if
later,
if
that
that
is
attribute,
is
promoted
to
be
in
the
spec,
then
there's
a
then
you
know
we
take
it
out.
C
There's
a
backward
compatibility
issue
so
looks
like
put
into
the
I
think
the
inclination
is
put
into
everything
into
one
big
bag.
Has
that
issue
right,
but
I'm
thinking,
you
know
whether
I
would
like
to
open
up
for
discussion,
whether
we
it's
good
to
have.
You
know
on
different
classification
bags.
I
think
you
know
for
that,
for
the
issue
looks
like
a
you
know.
If
we
have
multiple
classification
bags,
your
concern
that
people
is
going
to
put
the
same
information
in
different
bags,
but
I'm
thinking
you
know
it
should
be
only
in
one
bag.
C
If
those
those
classification
are
defined.
Well,
then,
you
know
the
event
producer
will
know
where
to
put
that
it
has
nothing
to
do
how
the
event
consumer
use
it.
They
are
two
separate
are,
and
it
is.
We
should
not
mix
them
together,
but
how
to
do
the
classification
I
think
should
be
from
the
even
producers
point
of
view.
You
know
what
kind
of
information
on
put
into
which
back
I
think
you
know
put
everything
a
top-level.
C
There
would
be
good
there
going
to
be
a
lot
rise,
thousands
of
different
informations,
so
it
doesn't
seem
to
be
very
good,
put
everything
under
one
big
bag.
It's
going
to
be
like
also
some
tons
of
under
that
one
bag
and
also
I,
think
you're
appointed
out
there's
a
issue.
We
saw
backward
compatibility,
but
if
you
put
something
to
the
different
classification
back,
there
will
be
no
backward
compatibility
issue
because
you
know
even
you
promote
it.
It's
still
going
to
be
in
that
classification
attribute.
C
B
C
B
But
if
we
know
if
we
have
something
in
a
classification
and
we
promote
it,
does
that
mean
that
now
that
classification
needs
a
spec
of
what
is
part,
needs
a
list
of
what
is
part
of
the
specification
that
goes
in
that
classification?
And
you,
then,
can
you
not
put
things
in
there
that
aren't
part
of
the
specification
or
what
like,
because
the
thing
with
the
classifications
that
I
think
we
can
do
is
that
you
can
define
your
own
bat.
You
can
define
your
own
extension
and
make
it
a
bag.
B
If
you
want
it's
just
that,
that's
not
really
part
of
the
spec
you're
free
to
do
it,
though,
and
you're
free
to
put
limits
on
it.
So
how
big
it
can
be,
how
many
records
it
can
have,
how
the
semantics
of
it
work
where
it's
like
the
thing
that's
kind
of
concerning
me
and
I
mean
being
a
like
a
lifetime
messaging
person
I
come
from
a
background
where
the
publisher
probably
knew
more
about
the
message
than
then.
C
C
Okay
in
the
producer
put,
the
information
into
a
producer
know
save
and
the
best
so
I
put
the
cross.
If
it
could
some
people
put
whatever
information
into
that
classification
category
right,
how
do
they
even
consumer
use
it?
The
event
consumer
has
to
look
into
those
information
to
see
which
information
you
know
he
cares
or
she
cares
and
which
doesn't
care
if
it
doesn't
care,
he
just
ignore
the
whole
bag.
B
B
Same
thing
can
be
accomplished,
though,
with
them
with
your
own
bag,
with
your
own
root-level
extension,
because
the
consumer
has
to
know
what
they're
looking
for
and
and
I
think
it's
easier
to
just
say
anything
that
when
you
look
at
the
cloud
advanced
version,
anything
that's
not
in
the
spec
we
know
is
an
extension.
So
it
then
it's
easy
to
say:
if
I
really
only
care
about
the
spec,
then
anything
that
doesn't
match
what's
in
the
spec
I,
don't
need
to
look
at
or
if
I
really
care
about
something
called
some
field.
B
D
B
Want
people
to
do
that
yeah,
but
we
want
them
and
and
if
it's
a
successful
bag
we
can
promote
it
in
the
future,
and
we
can
say:
hey
you,
this
type
of
bag
turned
out
to
be
really
successful,
so
this
should
actually
become
part
of
our
spec,
and
that's
where
things
that
you
know
might
be
vertical
specific
could
actually
kind
of
happen
and
graduate
into
our
spec.
That
I
think
would
be
a
good
idea
rather
than
putting
out
a
prescriptive.
Hey,
we're
gonna
make
these
classifications
and
you
have
to
fit
into
these
classifications.
B
D
The
mark
is
the
marker
will
tell
us,
as
long
as
we
create
an
opportunity
for
the
market
to
start
creating
these
these
classifications,
or
these
bags
and
I
think
the
best
way
to
do
that.
It's
going
to
be
to
put
it
at
the
top
level,
we'll
get
a
lot
of
great
data
from
that,
we'll
probably
be
able
to
make
more
informed
decisions.
C
Yeah
I
agree:
I
think
we
should
allow.
You
know
bags
at
the
top
level
because
you
never
know
right.
We
put
some
restrictions
say
you
know.
If
everything
you
know
no
bags
are
allowed,
I
think
we
should
allow
bags
and
also
from
also
as
an
event
producer.
So
if
I
see
some
bags,
I
see.
Oh
okay,
that's
that's
where
I
should
put
my
information
rather
than
I
just
put
into
one
big,
you
know
extension
bag
or
just
put
one
top
level.
I
rather
see
the
you
know,
there's
a
need.
You
know
for
that
classification.
C
There
are
other
particles
out
there
standard
particles
that
have
bags.
For
example,
there's
a
nurse
I
think
he's
I
forgot,
which
one
okay,
but
it
has
an
application.
Poverty's
back,
that's
a
standard
particle,
so
that
meant
there's
several
many
others.
So
why
should
he
here?
We
should
restrict
it
say:
no
bags.
E
Yeah
clarify
something
seems
like
I'm,
not
I'm,
not
sure.
If
I
hear
the
proposal.
Clearly,
my
understanding
from
the
discussion
is,
we
were
just
not
allow
not
Allah
not
put
any
first-class
bags
for
now,
but
allow
users
to
create
their
own
customized
bags
on
the
top
level
and
in
the
future.
If
some
bags
are
really
popular,
we're
going
to
promote
it
and
the
promote
would
basically
be
seamless
because
it's
still
basically
the
same
place
we
just
make
it
official
is
that
a
proposal
all.
A
F
B
F
H
C
I
So
when
my
main
point
is
that
I
think
of
cloud
events
is
defining
the
the
routing
and
some
level
of
classification
of
their
events
and
I
worry
that
the
consumers
are
people
that
people
that
are
using,
it
will
start
putting
more
data
into
the
headers
into
the
cloud
of
anthem,
as
opposed
to
the
data
of
the
event
itself.
And
we
need
to.
We
need
to
provide
guidance
there
to
ensure
that
that
people
put
all
of
the
event
either
down
in
theta
and
not
into
all
of
these
headers
I.
B
Think
that
the
default
needs
to
be
that
event.
Data
goes
in
data
you're
free
to
to
crack
the
data,
especially
if
you're
a
consumer.
You
know
what
it
is,
but
I
think
you've
hit
the
nail
on
the
head,
which
is
that
what
we
need
to
stress
the
kind
of
the
routing
aspect
and
the
kind
of
minimalist
aspect
to
to
make
sure
that
we
don't
get
into
a
place
where
we're
talking
about
soap.
No,
no,
no
offense
to
anyone
on
the
call.
I'm,
sorry,
I
didn't
think
before
I
said
that
comment.
D
J
The
reason
I
want
to
push
for
this
is
because
we
cannot
like
it
seems
like
it's
harder
for
us
to
move
forward
if
it's
an
extension
or
if
it's
not
in
extensions,
and
if
it
is
so
like.
What's
the
reason
that
we
can't
go
forward
if
it'd
been
a
sentence
like
I,
also
want
to
like
just
move
past,
this
I
don't
see
why
moving
it
to
that's
top
level
is
the
way
to
go
forward.
B
J
B
F
Let
me
understand
what
she
said:
I
believe
what
you
said
is
you
would
like
well-defined
bags
at
the
top
level,
but
inside
those
well-defined
bags
the
users
can
put
what
they
want.
For
example,
someone
could
put
something
like
what
Kathy
is
saying
identification
label
so
that
is
well-defined
but
inside
the
bag.
The
app
developer
can
put
whatever
labels
he
wants.
Does
that
make
sense.
F
I'm
saying
is
we
define
at
the
top
level
a
well-defined
bag?
I
like
that
idea.
There
are
a
couple
of
guys
on
the
chat
have
said
something
like
a
system
labels
or
some
information
identification
label
now
I
understand
the
concerns
of
those
who
say
there
will
be
thousands
of
that
of
them,
and
then
it
loses
its
value.
My
take
is,
there
won't
be
thousands
of
top-level
bags.
We
define
only
looks
like
one
or
two.
C
Yeah
I
would
like
to
clarify
why
the
reason
is
inside
it.
You
know
we
cannot
predefined
those
labels
so
for
different
events,
or
you
know
those
labels
will
be
different,
but
the
back
will
not
change
it's
all
identification
labels,
for
example,
for
our
event
source.
That's
in
a
interior
motion
detection.
You
know
the
label
could
be
something
related
to
that
address,
but
for.
B
C
You
know
a
storage,
a
storage
event
source
the
neighbor
could
be
up
the
bucket
okay,
but
but
it
will
not
be
thousands
of
labels
in
that
bag
OB
just
a
few
because
for
specific
event,
you
know
the
identification.
Labels
won't
be
huge,
but
because
of
you
know
different
events
from
horses.
They
have
you
know
labels.
So
the
only
way
we
can
normalize
it.
We
can
extract
a
common
part.
Is
you
know
some?
It's
called
identification.
C
You
know
label
back,
so
people
can
put
information
there,
and
this
is
important
because
you
know
there's
something
even
producer.
They
could
have
some
additional
information
they
would
like
to
put
there
and
so
that
you
know
it
would
make
it
easier,
make
the
consumer
easier
to
get
those
information.
Otherwise,
if
everything
is
in
the
data.
H
C
H
A
so
I
supported,
if
you
can't
you
shouldn't,
just,
have
blocked
that
Fox
data,
it's
useless
to
anybody.
You
need
to
have
an
identification
system.
We
use
your
eyes
to
identify,
perhaps
a
specification
you
could
go
to.
So
if
this
is
sensor
data-
or
this
is
whatever
data,
you
have
an
identifier
that
says
this
is
have
two
in
it,
and
your
I
can
be
version.
So
as
that
data
changes,
it
can
be
against
a
spec.
It
can
be
tracked
and
so
that
you
can
go
there
to
know
how
to
parse
this
black
box.
J
B
Our
schema
already
provides
a
way
for
you
to
tell
what's
in
the
data
and
what
I'm
trying
to
figure
out
here
is.
Why
does
this?
What
is
special
about
this
like
sensor
data
or
something
else
that
makes
it
so
wouldn't
go,
and
the
data
payload,
and
that
we're
putting
in
a
place
where
we're
designing
routing
based
on
it.
C
So
it's
not
just
for
routing
purpose,
so,
okay,
so
for
my
from
my
perspective,
I
would
like
to
use
it.
This
is
not
I'm,
not
you
know.
I
know,
I
mean
even
consumer
point
of
view
and
now
using
it
as
a
routing
purpose
or
using
it
as
to
correlate
the
event
with
other
events
associated
with
the
same
application
for
that
purpose,
but
you
know
I
think
you
know
in
that,
so
so
I
would
like
to
explore
a
bit
in
the
data
field.
C
So
if
the
data
is
encrypted,
okay
I
mean
how
could
the
user
I
mean
if
he's
encrypted?
It
would
be
hard.
You
know
to
get
all
those
information
and
I
think
my
head
before
say
you
know
it's
better.
We
put
you
know
other.
You
know
extract
that
out
and
put
it
into
a
bag.
I
think
if
someone
has
concerns,
if
is
in
the
encrypted
data,
they.
B
Think
I,
don't
think
any
of
us
are
in
a
position
to
say
where
I
mean
all
all
of
us
are
involved,
probably
and
serverless
in
some
way,
if
I
mean
I,
don't
know
about
anyone
else,
but
if
I
knew
where
server
list
was
going
to
be
in
five
years,
I'd
probably
have
a
different
job
than
I
do
right
now
so
I
mean
I,
don't
think
I
think
it's
very
bold
for
us
to
say
we
know
how
to
do
this
classification.
We
know
what
people
are
gonna
use,
I.
Think
it's
much
easier
to
say.
K
The
GC
and
protocol
team,
and
one
concern
that
I
have
is
that
if
we
let
people
add
key
value
pairs
or
data
at
the
top
level,
what
would
happen
is
that
we
would
have
to
actually
marshal
this
entire
data
before
we
can
decide
what
we
want
and
what
we
don't
want.
Instead,
if
you
had
like
an
extensions
and
then
put
the
data
that
we
want
in
there,
then
we
can.
K
J
Arbiter,
so
people
are
gonna
disagree
about
what
arbitrary
means
right,
yeah
I
portray
to
one
person
is
essentially
objects,
the
other.
The
point
is
like
the
point
that
I
would
like
to
make.
Is
that
it's
about
and
and
feel
free
to
interrupt
me
if
I'm
getting
this
wrong,
but
it's
that
we
need
to
understand
what
kind
of
data
will
be
like.
What
kind
of
data
are
we
expecting
here
and
if
we're
getting
arbitrary
data
anywhere
in
the
anywhere
in
the
properties,
then
that's
harder
for
us
to
do.
Did
I
get
that
right.
K
A
A
A
Specification
of
the
spec
itself
tells
you
what's
required,
which
is
optional,
so
in
version
1.1
of
the
spec
we
would
have
to
say
there's
a
new
top-level
property
called
some
label
and
it
would
be
marked
as
optional
and
that's
why
one
point,
though,
receivers
should
be
prepared
for
extra
stuff
at
the
top
level.
Exactly
for
that
reason,
new
things
may
get
added
to
the
spec
that
are
non-breaking
changes,
which
is
why
I
said
it
would
be
optional,
but
so.
K
K
Like
every
receiver,
in
addition
to
receiving
the
data,
I'm
sorry
I'm
new
to
this.
So
sorry,
if
I'm
asking
like
dumb
questions
but
every
if
that
means
that
every
receiver,
the
receives
this
data
should
not
just
have
this
data,
but
it
should
have
an
understanding
of
the
spec,
that's
defined
outside
the
data,
its
received
to
actually
make
decisions
on
each
of
the
key
value.
Can
we
encode
this
in
in
some
ways
what
I'm
suggesting,
which
is
that,
if
you
have
an
extensions
back,
then
then
everything
at
the
top
level?
A
We
can
say
this
in
my
experience.
It
is
very
common
for
people
in
Jason
to
add
new
properties,
especially
at
the
top
level
and
I
think
it
would
be
a
mistake
for
a
receiver
to
blindly
drop
them
on
the
floor,
especially
when
those
exact
same
labels
when
sterilizes
ACP
headers
will
appear
so
basically
I'm,
whether
you're
in
binary
structure
Jason,
you
may
get
different
results
as
an
application.
I.
K
C
C
I
think
we
agree
that
you
know
we
do
not
put
restriction,
say
you
know
you
can
only
you
know
the
format
of
the
of
new
pop
rates
right.
It
could
be.
You
know
some
label,
it
could
be
some
bags
I
think
if
we
are
putting
restriction,
say
or
not
restriction,
so
how
many
people
is
going
to
use
this
I
think
our
purposes
you
would
like
this
to
be.
You
know
two
more
people
to
use
it
right
right.
B
K
J
J
B
We
do
that,
though,
and
I
have
a
bunch
of
customers
using
1.0
and
I
mean
I
actively
have
customers
using
our
draft
right
now.
I
actually
have
actively
customers
using
a
ten-year-old
messaging
service.
Right
now,
which
is
a
cloud
service
and
I
have
literally
am
spending
half
my
day.
Making
phone
calls
right
now
to
try
and
get
them
to
upgrade
because
they're
using
ten-year-old
software.
Okay,
what
do
we
do
when
we
add
one
point
one?
B
So
they
just
won't
get
the
like
they're
designed
their
their
software
was
designed
just
to
ignore
everything
at
the
top
level
that
wasn't
explicitly
listed
in
1.0,
or
should
we
kind
of
push
the
industry
to
be
prepared
for
other
things
at
the
top
level
so
that
you
don't
have
the
versioning
pane?
That's
that's
naturally
going
to
come
your
way,
because
things
will
get
added
over
time.
A
That's
that's
the
part
that
I
think
drove
me
the
most
towards
this
model.
Is
this
notion
of
receivers
blindly
ignoring
things,
the
top
level
which
is
going
to
completely
break
an
old
receiver
talking
to
a
new
producer
and
the
notion
of
when
things
do
get
promoted,
people
have
to
change
code
right
because
things
are
moving
from
inside
the
bag
outside
the
bag,
and
then
do
consumers
not
have
to
put
it
in
both
places
because
they
don't
know
whether
they're
talking
to
old
or
new
consumers.
I.
J
A
B
That's
an
engineering
challenge
that
we
all
have
to
overcome,
but
what
I
can
say
is
a
middleware
person
is
that
my
middleware
is
going
to
need
to
be
able
to
pass
stuff.
That's
not
in
versions
of
the
spec
I
need
to
be
flexible
enough
for
that
or
none
of
my
consumers
can
upgrade
till
I
upgrade.
And
what
we're
proposing
with
this
whole
initiative
is
not
a
point-to-point,
not
a
client-server
model.
B
C
C
For
example,
if
there's
like
the
extension,
it's
not
extension,
it's
called
system
info,
then
you
know
instead
system
info,
you
have,
you
know,
I
just
make
it
up
a
CPU,
CPU
or
whatever
requirement
it
might
not
apply
to
the
event,
but
just
that,
why
do
you
remove
that
system
info?
There's
no
need
so.
There's
no
upgrade
here.
A
C
Okay,
it's
all
I'm
hearing
that
because
so
you
know
when
you
upgrade
from
extension
to
the
men's
back,
you
know
the
back
name
is
removed.
For
example,
if
the
back
name
is
called
system
info
or
a
patient
label,
then
that's
removed,
so
there's
a
backward
compatibility
issue.
My
point
is
that
when
you
upgrade
that
there's
no
there's
no
need
to
remove
that,
because
that's
a
that's
it
that's
the
attribute
name.
The
system
info
is
the
attribute
name
so.
C
When
I
say
he's
promoted,
it's
not
promote
all
this
calm
example.
Extension
is
promote
this
like
I.
Take
this
attribute.
It's
called
just
remove
that
extension.
You
know
just
a
coil
system
info
you're,
promoting
the
system
info,
any
specific
information
inside
that
system
info.
It's
all
the
same
information
your
promo
put
in
that
system
info.
That's
the
attribute,
the
the
format
of
the
attribute.
It's
like
a
map,
format
right
the
format
and
then
in
the
specific
you
know
where
I
do
so.
Here
is
not
you
know
this
system
info.
It's
not
just
one
value.
B
C
A
root
at
the
root,
there's
no
I
I,
don't
think
that
we
need
another
of
you
know
just
that
a
station
keyword.
We
have
different
bags
right.
You
have
system
info,
I
will
not
see
a
lot,
but
you
maybe
have
a
few.
Why
there's
no
need
to
put
another
extension
on
top
of
it
and
when
you
see
realize
it
you're
just
serious
same
as
you
know,
the
event
type
or
even
even
type
or
event,
time
time
or
source
right
just
like
the
sourcing
for
people
can
put
different
super
seam
for
the
air.
We
cannot
predict.
C
What
kind
of
sourcing
for
will
be
put
there
I
might
take
is
that
we
do
not
know
how
you
know.
We
cannot
predict
future
how
people
is
going
to
you
know
the
event
producer.
It's
going.
How
they
are
going
to
you
know,
use
this
so
I
think
it's
more
open,
more
flexible,
I!
Think
more
people
is
going
to
use
it.
If
we
put
a
lot
of
restrictions
say
we
cannot
allow
this.
We
cannot
allow
that
we
only
allow
a
single
key
value
pair
at
the
top
level
at
the
root
level.
C
B
B
C
F
A
C
Believin
producer
and
then,
if
we
think
it's
yeah,
oh
by
by
this
group
right
just
like
we
define
in
this
event
an
event
type,
you
know,
and
then
we
define
source
right
source
itself.
You
know,
could
be
a
bag.
You
know
I,
you
know
we
need
to
take
a
look
at
the
source
itself.
If
it's
a
matte
format,
it
could
be
a
bag
too
I
just
want
the
no
restriction
say
we
only
need
one.
We
only
are
not
one
format,
which
is
are
just
a
key
value.
C
E
I
think
that
I
thought
the
the
discussion
was
really
between
whether
we
put
whatever
you
say
it
in
our
main
spec
or
we
allow
users
to
or
producers
to
define
them
arbitrary
I
thought
that
was
the
discussion
and
when
the
JSON
side
says
I
think
we
both
agree.
We
need
that
I
thought
that
this
difference
was
one
side
says
we
do
not
puts
out
those
into
the
main
spec.
So.
A
C
Okay,
so
even
producer
can
add,
you
know,
system
info
or
whatever
other
name,
that's
more
appropriate.
You
know
in
at
the
top
level
extension
we
can
also
define
such
structure
other
in
the
men's
back
at
the
root
level,
yeah.
So,
okay,
my
whole
point
is
just
we
do
not.
We
put
industry
in
restriction
and
the
format
of
the
metadata,
no
matter
whether
is
in
the
men's
style,
or
it's
in
the
extension
or
is
it
is
extension?
C
That's
my
point:
do
we
need
to
put
any
restriction
there
and
then
the
ones
of
anything
is
promoted
from
the
from
the
extension
to
the
1s
extension.
It's
not
the
extension
back.
Okay,
what
I
mean
is
anything
is
promoted
for
you
know
from
not
it
from
Longman's
back
to
the
men's
back.
We
do
not
need
to
add
any
extra
tag,
like
extension,
that
keyword
tag
there.
What
do
you
say
they
find?
You
know
in
the
nouns
back
if
its
core
system
in
for
when
we
promote
it,
it's
still
core
system
info.
D
B
D
I
think
we've
been
going
over
this
issue
for
months
and
we've
been
going
in
circles
and
a
lot
of
it.
You
know
new
people
join
the
conversation,
they
don't
have
the
context
and
they
they
haven't
been
involved
in
the
earlier
conversations.
I
think
we
I
think
the
bigger
issue
is
just
is
the
lack
of
decision
velocity
here
and
I
think
we
should
just.
D
G
We
there
needs
to
be
a
defense
of
like
the
reasons
why
it
is
a
value
and
I
guess
feel,
like
the
conversation
hasn't
had
that,
like
there's
been
concerns
raised
about
how
this
gets
encoded
in
binary
protocols
and
maybe
having
a
a
presentation
or
multiple
presentations
like
I,
think
we
talked
through
Kathy's
concern
where
it's
it
seems
like.
That's
like
that's
now
part
of
this
proposal.
So
that's
progress,
but
you
know
I
can
get
there.
Are
people
struggling
to
actually
implement
this
in
things
other
than
JSON
right.
A
And
then
you
had
asked
for
people
who
were
not.
You
know
like
the
G,
RPC
and
protobuf
people
to
speak
up
and
I,
don't
think
they
got
a
chance
to
yet,
but
I
apologize
I'm
not
still
used
to
zoom
with
their
little
hand,
thing
glad
I
think
you
try
to
put
your
hand
up
at
least
that's
what
it
looks
like
yeah.
L
I
have
all
I
discussed
a
bit
about
the
promotion
and
getting
something
from
an
extension
to
an
official
table
level
attribute.
What
does
the
group
wanted
this
level
as
in
doing
both
forward
and
backward
compatibility?
What,
if
I
define
table
level
expansion
called
tracing
where
I
just
put
in
a
face?
Id
and
then
the
Mac
comes
up
and
promotes
another
official
extension
that
is
open,
tracing
compatible
and
it's
an
ID
and
straight
ID
how's
that
gonna
be
handle,
and
what
do
we
do?
How
are
we
gonna
do
this?
L
There
were
discussions
about
ok,
this
cheating
and
they
thought
this
might
be
mirrored
in
the
data,
but
data
mighty
encrypted
first
I
mean
whatever,
and
the
point
was
that
extension
could
be
modified
by
middleware
without
actually
modifying
data,
say
adding
extensions.
I
wrote
a
huge
comment
on
that
seems
like
these
two
topics:
promotion
and
encryption.
Finding
whatever
has
been
a
bit
ignored,
are
they
were
just
discussing
in
this
context
because
it
seems
like
it's
affecting
good,
also
yeah
I
do
agree.
L
A
So
we're
running
a
little
low
on
time
here.
It
I
heard
a
couple
of
different
suggestions
for
topics
to
be
brought
up
and
for
discussions,
glad
you
just
head
to
the
promotion
discussion
and
then
the
encryption
stuff-
I'm,
not
honest,
a
I'm,
not
quite
sure
about
the
encryption
stuff
in
terms
of
how
that
100%
relates
to
this.
But
is
someone
willing
to
talk
about
those
two
issues,
because
we
talked
a
little
bit
about
about
the
promotion
already
today,
but
it
was.
It
was
in
fate.
A
C
A
K
I'm
in
the
next
meeting,
like
one
thing
that
we
could
do
is
let's,
let's
actually
have
like
I
could
I
could
take
maybe
five
or
ten
minutes
and
put
like
two
three
slides
on
on
the
problems
that
we're
heading
up
against
a
spec
from
a
protocol
definition
perspective
and
also
compare
and
contrast
both
of
these
options
and
see
how
that
would
look
in
the
protobuf
spec
so
that
we
can
talk
to
some
concrete
details
as
to
how
this
would
look
outside
of
the
JSON
land.
Would
that.
A
K
D
K
A
D
J
J
A
I
was
gonna
mention
that
between
now
and
then
I'm
gonna
try
to
work
on
exactly
what
we're
voting
on
because,
as
you
said,
there
are
many
different
issues
at
play
here
and
it's
not
Harper
Sinclair,
but
it's
on
the
same
page
about
which
issue
we're
talking
about
so
I'm
gonna
try
to
get
some
clarity
there
before
we
actually
look.
Yes,.
C
Yeah
so
I
think
yeah
I
agree
with
Rachel.
There
are
several
issues
you
know
looks
like
being
discussed
here.
I.
Think
one
issue
is
today's
discussion.
Is
you
know
what
kind
of
I
think
is
a
format
right
be
allowed
in
the
extension
or
in
the
men's
back
and
then
another
is
how
to
promote
this
right,
so
I
think
even
for
the
first
one
we
have
different
suggestions,
so
I
would
suggest
you
know
each
person
present
the
suggestion.
I
can
present
my
suggestion
and
then
maybe
there
are
other
two
suggestion.
C
I
see,
why
is
everything
put
into
extension
back
and
the
second
one
is
everything
top
level?
And
but
my
suggestion
is,
you
know
at
the
top
level,
but
we
are
now
you
know
different
format.
We
are
now
key
value
pair.
We
are
now
max,
so
we
can
probably
present
each
other's
presents
the
suggestion
proposal
and
then
people
can
vote.
A
C
A
A
A
This
call
you'll
want
an
implementation
experience
for
why
we
need
to
do
something
one
way
or
the
other,
and
so
anything
you
can
bring
to
the
table
would
be
very,
very
useful
in
that
respect.
Okay,
and
with
that
we
have
one
minute
left,
I'm
gonna
have
to
call
it.
Let
me
just
go
back
and
do
the
roll
call
if
we
can
very
quickly
there's
some
typing,
the
back
of
makes
it
hard
to
hear
Rohit.
Are
you
there
Rohit
you
there,
okay,
Chris
Hanson
you
there
yeah
okay
Chris?
A
What
about
Eric,
Staal,
Bullock
or
Erik
Erikson
Erik
Erikson's,
here,
okay,
here
Rachel
I
heard
Klaus
you
there?
Yes
I'm!
You!
Thank
you!
Louie!
Are
you
there
yeah
I'm
here,
okay,
come
back
around
Eric
you're
there
stoic
Stoli
cool
I
apologize,
I
wrote
it
is
there
anybody
I,
missed
on
the
attendance.