►
From YouTube: CNCF Serverless WG Meeting - 2018-07-12
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
D
The
community
today,
regarding
expansions
and
what
we
aren't
currently
helping
the
startup
and
they're,
exploring
the
idea
of
using
cloud
even
inside
the
application
to
you
as
in
event,
spend
it
in
function.
The
Accord
events
tier
and
we're
right
now
exploring.
How
would
the
payload
the
data
field
and
how
event
should
be
structured,
I
wanted
to
ask
community
if
anybody's
done
any
research
into
this,
and
if
they
have
any
schemas
or
examples
they
could
share.
D
I
know
this
was
also
brought
up
during
the
indicate
you
all,
because
I
was
a
talk
about
having
about
converting
event
to
cloud
even
say:
converting
s/3
s/3
in
the
file
event
is
called
event
put
objects
or
stuff
like
that.
Is
there
kima
for
how
data
should
look
in
that
context?
Is
there
anything
else?
Yeah
I
want
to
avoid
terrible,
XML,
a
soap
and
whatever
so
that.
E
So
just
be
aware:
yeah,
that's
what
I'm,
because,
because,
if
you,
if
you,
you
know
as
long
as
the
character
is
preserved
of-
and
this
is
just
my
opinion,
as
long
as
the
character
is
preserved
event
of
these
events
being
one
way
things
and
you
don't
start
building
their
PC
framework
on
top
of
of
the
quality
of
on
its
envelope,
see
that's
okay,
but
from
a
standards
perspective.
I
think
we
explicitly
don't
want
to
be
concerned
with
what
the
data
contains,
and
it's
really
just
up
to
you.
B
D
Deeply
agree
that
what
event
site
shouldn't
add
any
restrictions
regarding
the
payload
but
I
know
I
was
just
curious.
There
is
obviously
no
best
practices,
because
this
is
super
super
early
and
there
is
not
even
it
and
there's
a
K
at,
but
I
would
steal
what
ideas
ever
have
and
I
want
to
avoid.
As
many
mistakes
of
Ajax
at
least
I'd
should
make
new
mistakes.
E
And
maybe
maybe
something
will
help
kind
of
on
the
on
the
since
we're
clients,
our
implementations
are
by
ways
of
a
mapper,
but
we
do
have.
We
have
some
some
internal
guidelines
on
how
we
think
about
structuring
you
know,
event
payloads
and
there's
kind
of
a
common
set
of
events,
kind
of
the
outer
level,
then
there's
kind
of
the
the
the
omitting
service
has
a
set
of
properties
that
defines
and
then
the
respect
the
function
has
one.
E
We
call
this
the
acid
more
thing,
which
is
the
acid
move
model
which
is
ABC,
and
so
the
a
is
affecting
you
define
for
the
platform.
What
payload
parameters
always
need
to
be
in
an
event,
and
that
might
also
define
for
yourself.
You
know
how
you
map
those
that
from
your
payload
into
the
cloud
of
ions
envelope,
what
you
promote,
then
B
is
effectively
for
the
respective
module
that
emits
all
the
functions
need
to
go
and
emit
the
same.
E
The
same
metadata
of
foreign
events,
so
that
you
can
go
and
parse
them
together
and
then
individual
individual
function
that
mid
stuff
taking
and
have
its
own
its
own
data,
so
that,
before
the
cloud
event
itself,
you
have
your
kind
of
your
sub
structure,
which
gives
you
a
way
to
enforce
criminality
across
the
system.
Commonality
across
the
module.
E
E
Put
me
put
make
a
note
in
the
in
the
in
the
notes
that
I'll
go
and
see
whether
I
can
find
the
the
ABC
events
schema
rules,
because
I
think
the
abstract
rules
are
really
useful,
even
if
we
don't
want
to
go
and
define
if
even
if
we
don't
want
to
be
specific
here,
how
they
should
look
like
I
think
some
best
practices
would
be
useful.
Yeah.
E
B
B
That's
where
that
it's
seven
days
old,
though
I'm
guessing
he
pasted
the
wrong
link
and
I
think
this
is
the
last
comment:
is
it
actually
the
latest
one
he
has
I
believe
he
did
tweak
some
of
the
spacing
around
the
scene?
The
e
I
am
when
I
was
talking
with
you
slack
earlier,
because
he
can
make
the
call
the
suggestion
was
to
present
it
to
you
guys
here.
B
Look
it
over
think
about
it
and
then
I
think
at
some
point,
whether
it's
next
week
or
maybe
it's
during
the
week
or
something
will
do
some
kind
of
vote
or
something
on
it
other
than
that
I'm,
not
quite
sure
what
you
guys
wanna.
Do
it
at
any
comments
on
this
suggestions,
I'm
third
way
to
proceed
or
commentaries
in
general.
Do
people
prefer
this
better
than
the
current
one
we
have
I
mean?
Does
it
look
like
it's
heading
the
right
direction
to
people
not
care.
C
B
I
think
the
sticker
is
gonna,
be
just
the
first
tube.
It's
not
the
tagline,
yeah
okay,
well,
I'll
tell
Austin
that
at
least
one
person
seems
like
its
head
in
the
right
direction.
No
other
complaints,
but
obviously
take
time
to
think
about
it
and
we'll
probably
review
it
again
on
next
week's
call,
if
not
through
the
email
list,
or
something
like
that,
but
all
right
any
other
comments
before
we
move
on
to
the
next
topic.
B
Alrighty
cool,
so
Austin
obviously,
is
not
on
to
talk
about
any
SDK
updates,
but
I
don't
think
there
are
any
other
than
to
say
he
did
a
doodle
poll
and,
according
to
doodle
poll,
he
believes
that
the
next
call
is
gonna,
be
July
18th
at
1:00
p.m.
Pacific
I
will
nag
him
to
send
out
a
calendar,
invite
to
make
sure
that
gets
put
out
there
for
everybody
to
accept.
B
F
F
C
B
F
To
be
more
yeah
here
so
here
we
have
consensus,
and
then
we
have
some
potential
specification
target.
Some
people
can
take
a
look
and
then
I
think
in
the
next
meeting.
We're
going
to
go
through
so
have
you
know
people
present
different
models
and
then
also
to
have
to
go
through
comments
on
the
spec,
so
that
people
have
thought
when
you
comment
feel
free
to
post
to
them.
Alga
will
go
doc.
B
You
guys
are
awfully
quiet
today,
I'm,
not
hearing
anything
okay,
Thank,
You,
Kathy,
we'll
keep
moving
forward.
Then
I,
don't
believe.
There's
anything
issue
maintenance
wise.
We
need
to
deal
with
today
at
least
I
apologize.
If
there
was
something
I
missed.
Oh
just
traveling,
so
I
missed
I
didn't
get
a
chance
to
do
a
thorough
scrub.
B
E
Yeah,
basically,
this
is
about
how
do
we
achieve
the
goal
of
interoperability
and
what
are
the?
What
are
the?
What
are
the
criteria
for
inclusion
of
of
protocols
into
the
core
of
the
specification
set,
and
when
does
it
make
sense
for
those
for
those
protocols
to
be
included
and
I
tried
to
make
a
basic
affair
rule
for
for
when
protocols
qualify
without
reading
the
text
to
you,
which
you're
all
very
capable
of
I,
think
the
general
the
general
direction
is
that
the
specification
needs
to
be
useful.
E
So
if
we
define
a
transport
binding
and
if
we
define
encoding
mappings,
those
specifications
must
be
useful
for
more
than
one
implementer,
because
otherwise
it
just
becomes
an
advertising
surface
and
that's
something
that
I
think
this
project
should,
if
we
can
avoid
to
promote
more
protocols
in
because
that's
that's
not
helping
interoperability.
So
if
someone
is
a
project
wants
to
go,
everybody
can
go
and
build
their
own
protocol,
of
course,
and
everybody
can
go
and
define
the
called
events
binding.
If
they
want
to.
E
So
this
is
what
this
as
well
and
I,
think
I
think
it
can
only
do
so
if
there
is
a
realistic
expectation
that
there
will
be
other
parties
and
I'm
not
sure
whether
it's
at
least
one
party,
or
at
least
two
parties,
but
other
parties
who
are
unrelated
to
that
project,
who
will
be
able
to
implement
a
mapping
to
the
protocol
using
that
specification
without
necessarily
having
to
talk
to
the
originators
of
of
that
project
in
its
protocols.
So,
for
instance,
at
I'll,
give
you
give
the
example
of
Kafka
Kafka.
It's
not
a
open
standard.
E
We
would
actually
benefit
from
from
having
such
having
such
a
definition
without
a
project
having
a
formal
protocol
definition
that
is
a
pure
wire
specification
that
that
is
it's
locked
down
so
that
it
doesn't
change
when
the
code
of
the
the
project,
changes
and
Kafka
qualifies
for
that,
it's
difficult
to
see
how
a
how
a
you
know,
specification
called
event.
Specification
general
one
that
sits
in
the
in
the
main
repository
helps
I
think
with
formal
interoperability
standards.
Protocol
standards.
That
story
is
a
very
different
one.
E
Nkg
T
and
H
P
and
n
QP
are
effectively
protocol.
First
efforts
where
you
first
define
the
protocol,
and
then
you
define
a
variety
of
different
products
that
all
use
them
and
where
additional
specifications
and
these
extensions
mystifications
they
clarify
their
use
on
that
protocol.
Clearly
help
in
the
concrete
case
of
poles
are
so
I
have
to
go
to
pick
up
on
that
one,
because
that's
the
example:
it's
not
clear
or
actually
also
the
other
PR.
That's
there
is
open
messaging.
E
It's
not
clear
to
me
how
the
existence
of
those
specifications
helps
anybody,
but
that
project
and
are
therefore
effectively
just
just
advertising
vehicles
for
those
projects.
Inside
of
the
the
cloud
events
repository.
So
that's
my
so
I'm
trying
to
set
a
rule
I'm
trying
to
write
a
rule
that
is
driven
by
the
usefulness
of
those
specifications,
and
it's
also
driven
by
the
spirit
of
not
everybody,
ought
to
go
wrong
and
and
just
create
their
own
protocol,
because
that
doesn't
help
interoperability.
E
What
we're
trying
to
do
is
we
try
to
unify
things
and
we're
not
trying
to
accommodate
28
different
protocols,
but
rather
go
and
and
really
pick
favorites
so
that
we
achieve
highest
possible
interoperability
and
effectively
the
papers
that
we
pick
are
different
enough,
that
they
that
they
cover
kind
of
the
broadest
possible
area.
We
have
HTTP
for
request
response
web
messaging.
We
have
mqtt
for
lightweight
pub/sub
and
we
have
inca
PE
for
in
a
transactional
messaging
and
there's
other
protocols
that
go
and
fill
similar
roles.
E
F
E
So
we
have,
we
have
an
T
DT,
we
have
n
QP
and
we
have.
We
have
HTTP
as
the
canonical
ones
and
that's
I'm
I'm,
not
sure
how
many
so
because
we
have
nets
in
the
repo
and
that's
I'm
not
sure
when
that
slips
through
the
cracks,
because
I
don't
know
how
many,
how
many
implementations
of
the
port
protocol
of
Nats
there
are.
E
E
And
and
so
that's
why
I
think
I
think
Nats
is
one
where
I
had
no
Nats
didn't
didn't
trigger
any
didn't
trigger
this
problem
with
me,
but
I
think
there's
a
as
if
there
are
efforts
that
are
kind
of
more.
You
know
there
are
open
source
projects
who
then
choose
to
go
and
define
their
own
protocols
rather
than
adopting
existing
ones.
It's
not
clear
how
that
new
protocol
is
rationalized
versus
the
existing
ones,
then
blessing.
Those
with
you
know,
official
support
from
the
cloud
events
project
is
actually
not
helping.
E
Websockets
is
a
very
broadly
adopted
mechanism
and
and
so
as
much
as
we're
mapping
to
http,
so
our
mapping
to
http
is
actually
generic,
so
it's
it
works.
Hp,
1hp
I
took
WebSockets
and
even
though
we
don't
have
an
official
binding
as
an
example,
that's
a
protocol
that
everybody
is
using
and
that
everybody
is-
and
everybody
means
it's
very
broadly
used
and
there
will
be
the
need
and
people
will
go
and
put
put
cloud
events
on
to
a
WebSocket.
The
question
is
whether
we
need
to
have
a
proper
binding
for
it.
E
H
Have
a
quick
question
on
my
understanding
is
that
the
events
would
be
part
of
the
payload
and
in
most
of
these
messaging
protocols,
the
payload
is
actually
a
serialization
problem
for
interoperability
versus
the
transport
problem
or,
if
I
can
get
it
to
the
producers
and
the
consumers,
regardless
of
the
transport.
I,
still
need
to
have
a
common
serialization
and
the
where
most
of
these
are.
H
You
know
how
do
I
represent
the
stream
a
map
or
do
I
use
just
a
binary
transport
and
use
something
like
Google
protocol
buffers
or
some
other
serialization
to
represent
it,
where
I
don't
care
about
the
language
or
the
operating
system,
or
they
would
just
keep
it
as
JSON.
You
just
do
a
strength
serialization.
H
E
So
so
I
recommend
that
you
read
the
aim
capiz
specification
and
gives
the
mkdd
specifications,
because
they
are
actually
doing
exactly
that.
So
those
two
specs
take
a
cloud
events
our
info
set,
which
is
our
abstract
model
and
actually
project
them
onto
an
MVP
message
and
projects
them
unto
the
MQTT
published
packet
and
basically
take
things
from
our
abstract
model
like,
for
instance,
the
content
side
and
project
them
onto
the
appropriate
property
in
the
end,
publish
package
and
unto
the
appropriate
property
in
the
MVP
package.
E
So
it's
not
just
that
they
take
the
event
and
just
stuff
it
into
the
into
the
payload.
We
actually
define
our
defining
rules
for
how
that
actually
works.
So
we
have
a.
We
have
media
types
that
are
appropriate
which
are
indicating
to
the
receiver
that
this
is
an
MVP
called
event.
That's
carried
in
the
payload.
If
we're
using
the
structured
mapping,
we
also
have
a
way
to
go,
and
if
you
don't
want
to
use
this
jason
serialization
but
you're
actually
carrying
significant
size
data
payloads
are
binary.
E
We
have
a
binary
mapping
and
we
have
to
define
so
so.
Basically,
what
the
transport
the
transport
mappings
are
do
that
we
have
in
the
in
the
repository
today
is
there
are
defining
rules
for
how
to
take
a
call
to
vet
and
project
that
out
onto
the
HTTP
message
onto
the
MVP
message
and
onto
the
Infinity
publish
packet.
E
Okay,
I'll
definitely
have
a
closer
look
at
that.
Yes,
it's
this
really.
Is
it
explicitly
the
reason
we're
doing?
That
is
because
we
want
to
have
broad
interoperability,
and
we
just
want
to
make
sure
that
if
a
if
a
colony
van
gets
stuff
into
HTP
request
on
one
side
that
it
gets
comes
out
understood
as
an
as
a
cloud
offensive
and
on
the
other
side
and
more
importantly,
if
you
have
multiple
routes
over
messaging
systems
and
where
the
message
also
gets
stored
on
this
and
sorry
for
the
church
bells.
E
In
the
background,
if
it
gets
stored
on
this,
you
know
and
then
gets
resurrected,
and
then
probably
someone
else
said
basically
that
integrity
of
the
message
is
preserved,
it
never
gets
lost,
and
and
for
that,
it's
required
that
we
actually
have
a
clear
notion
of
what
the
projection
looks
like.
So
take
a
look
at
the
specs
okay.
B
Did
me
this
is
one
of
those
things
where
it's
a
potentially
very
touchy.
Subject:
political
in
nature,
but
if
we
are
going
to
have
some
sort
of
bar
at
all
in
terms
of
what
we
accept
for
specifications
into
our
repo,
then
obviously
we
got
there
very
clearly
defined
that
bar
and
I
think
this
is
a
good
step
at
defining
that
bar.
So
let
me
ask
the
high-order
question:
do
people
object
to
defining
a
bar
at
all,
or
should
we
allow
everything
in.
I
E
I
B
I
F
E
B
Okay,
so
I'm
not
hearing
any
objections
to
defining
a
bar.
So
now
the
question
then
is:
is
the
bar
that
Clements
here
has
defined
the
appropriate
one
for
us
to
have
at
this
time
as
I
said,
I'm
not
gonna
push
our
vote
on
this
today,
because
I
suspect
most
people
have
not
had
a
chance
to
read
it,
but
given
what
Clements
has
described,
does
it
sound
like
it's
the
right
general
direction
for
people
or
do
people
have
concerns
with
the
way
he
described
it?
B
J
Only
concern
I
would
potentially
have
here
and
it's
not
that
the
people
wouldn't
pay
I
just
I
am
it
feels
like
we're,
making
a
bit
of
an
exception
for
apache'
Kafka's,
specifically
and
I
understand
you
know
the
reasoning
behind
it
here,
I'm
just
wondering.
If,
if
you
know,
are
we
concerned
at
all
about
that,
slipping
in
I,
think
struggling
with
that.
E
And
I
think
what
the
risk
Africa
is
special
and
I
don't
currently
see
at
least
from
where
I
sit.
I
don't
see
anything
that
is
even
close
to
that
right
now,
as
in
terms
of
category
to
finding
like
there's
a
there's,
a
pattern
that
is
currently
taking
effectively
by
like
if
you
look
at
large
installations
like
just
volume
of
stuff
that
goes
through
it
there's
effectively
too
large.
E
Well,
three
large
implementations,
right,
there's,
Kinesis,
there's
inventives
and
then
there's
Kafka,
which
is
what
everybody
else
is
using,
so
that
protocol
has
become
if
the
facto,
the
way,
how
you
do
event
and
just
ingest
and
and
and
and
greeting
so
it's
there
hasn't
been.
There
hasn't
been
a
formal
standards
body
for
then
first
meet
that
protocol,
but
kevin
has
emerged
out
of
a
multi
multi
company
collaboration,
that
is
the
passion,
Kafka
project
and
they
have
had
the
discipline
to
go
and
and
put
a
protocol
spec
up
that
actually
holds
up
to
third-party
implementation.
E
E
Yes,
protocol,
proprietor
project
proprietor
as
an
extension,
a
thing
that
we're
affecting
the
project
needs
to
go
on
to
find
its
mapping.
That's
fine
with
me
as
well!
So
if
we,
if
we
want
to
go
in
and
have
the
rule
that
there's
gotta
be
a
standard
protocol,
the
standard
protocol
protocol
needs
to
come
out
of
a
you
know,
multi-party
standardization
effort
and
only
then
we're
gonna
go
and
and
and
do
the
mappings
that
work
for
me
as
well.
K
Did
you
try
an
approach
conference
team
to
try
potentially
and
maybe
even
create
a
standard,
because
I
assume
you
know,
you
guys
have
a
compatible,
compatible
implementation,
every
version
deduction
something
that's
probably
probably
also
great
challenges
for
you.
We
also
have
a
compatible
limitation.
So
would
it
make
sense
to
try
and
get
them
to
write
some
protocol.
E
So
so
I
would
approach
the
the
Kafka
project
per
se,
and
not
necessarily
one
company
that
that
contributes
to
it.
We
we
actually
have
commuters
in
Microsoft,
will
work
in
LinkedIn
for
the
Kafka
project
and,
yes,
we
have
were
contemplating
whether
we
want
to
go
and
and
proposed
making
that
a
standard.
We
certainly
have
the
intent
of
showing
up
in
the
Kafka
project,
as
you
know,
braising
or
voice
in
the
protocol
side
of
this,
but
that's
in
the
early
stages,
I
think
I
think
that's
I.
E
So
for
implementation
of
it
we
certainly
have
interest
in
having
that
goal
in
an
orderly
fashion
and
not
just
go
where
the
the
Kafka
project
wants
to.
You
know
wants
things
to
go
at
the
same
time.
They
actually
have
a
pretty
good
community
process.
Now,
where
you
know
they
have
proposals
like
they
have
a
real
process
that
they
are
following
they're,
just
pretty
involved
and
and
they're
now,
shipping
confluent,
which
is
a
big
driver.
E
They
are
also
not
shipping
services,
which
is
I'm
going
to
curb
their
exuberance
of
adding
things,
and
so
I'm
happy
with
it.
Where
things
stand,
but
kind
of
kind
of
promoting
that
into
a
standard
thing
would
certainly
be
helpful.
So
we'll
have
to
have
a
conversation.
That's
a
conversation.
If
we
want
to
have
what
we
haven't
got
yet.
K
E
E
E
Do
we
do
we
make
a
draft
and
never
because
that's
the
other
way
to
do
it
right
you
can
you
make
a
draft,
you
put
it
into
the
repo,
but
never
make
it
part
of
the
part
of
the
official
part
of
the
original
standard,
but
just
have
something
for
people
to
look
at
or
oh
you
say:
nah
we
don't
care
about
Kafka.
The
problem
is
it
is.
It
is
such
a
dominant
thing
that
I
wonder
whether
we
are
damaging
our
own
effort.
If
we
don't
have
a
mapping
for
it.
B
B
B
G
So
let's
say
you
have
another
protocol.
Another
messaging
system
that
wants
to
integrate
down
the
road
in
a
few
years
is
there
gonna,
be
some
sort
of
you
know,
defined
defined
thing
that
this
messaging
system
or
transport
needs
to
meet
in
general,
just
generically
just
for
forward
thinking
or
would
they
have
to
go
through
the
same
process?
We're
going
to
now
I.
E
Think
they
would
have
to
meet
the
same
bar
in
terms
of
principles
like
their
their
protocol,
so
you
can't
come
with
a
messaging
system,
but
how
about
that?
You
can't
come
with
a
messaging
system.
You
actually
need
to
come
with
a
protocol
and
that
protocol
needs
to
be
implemented
not
just
by
that
messaging
system,
but
needs
to
be
implemented,
at
least
by
you
know
two
or
three
independent
efforts.
That's
that's!
Actually
the
bar
that
we
put
up
for
innovations
there
is
like.
E
If
you
want
to
promote
a
specification
into
a
into
an
official,
you
know,
release
spec.
You
must
prove
as
the
standards
project
even
that
there
you
have
at
least
three
independent
implementations
of
that
thing
and
I
think
that's
a
I
think
that's
a
good
measure
for
for
interoperability
that
you
can't
come
with
a
system.
You
can't
come
with
an
implementation.
You
really
need
to
come
with
in
drop
spec.
F
B
E
B
I
think
they'll
be
useful
because
well,
the
text
you
have
here
is
good
whoops
fudge.
Well,
the
texture
you
have
is
all
good.
It's
a
lot
to
read
and
I
think
narrowing
it
down
to
a
bulleted
list
that
people
can
digest
very
quickly
would
be
really
helpful
for
understanding
purposes.
The
TLDR
yes
exactly
yes,.
E
And
I
think
it's
important
that
there's
actually
affair
there.
We
had
a
discussion
on
the
in
the
in
the
PRS
and
the
issues
just
this
week
on
the
particular
PR
messaging,
where
there
is
actually
no
protocol
and
there's
no
encoding
to
map
to
and
if
that's
not
given,
then
you
can't
make
a
spec
because
that's
not
gonna
help
anybody.
It
literally
needs
to
be
like
there's
a
we
have
now
a
protocol.
E
A
protocol
architecture
has
emerged
here
where
we
have
an
abstract
data
model
and
that
maps
in
two
formats
and
apps
in
maps
at
the
protocols
and
if
there's
no
protocol
to
map
to
if
there's
no
event
formats
of
map
to
well,
then
you
can't
write
a
mapping,
and
so
that's
that's
something
that
we
and
that's
not.
You
know,
that's
you
know
evil
from,
but
by
me
to
give
that
feedback.
That's
just
the
fact
that
it
doesn't
fit
the
architecture.
So
I'll
summarize
that
into
into
a
few
bullets
as
an
extension
to
this
one,
that'd.
F
E
B
B
Well,
try
to
see
what
we
can
do
in
terms
of
voting
or
proving
it
next
week
or
discussing
next
week.
If
anything
big
comes
up,
you
may
have
to
defer
it
for
a
couple
weeks
as
Clemens
will
be
on
vacation,
but
it
does
not
controversial
then.
Maybe
we
can
get
it
in
we'll
see
how
it
goes
all
right:
cool,
Thank,
You
Clemens.
B
B
F
B
B
Right,
so
it's
a
for
example.
It's
the
question
of.
Do
we
want
to
allow
extensions
at
all
or
do
all
cloud
events
only
have
the
properties
that
we
just
find
in
r-spec
right.
That's
one
use
case
do
if
we
want
to.
If
the
answer
is
yes,
we
want
a
lot
extensions.
Then,
okay,
do
we
want
to
allow
extensions
only
in
an
extensions
bag,
or
do
we
want
to
allow
it
in
this
other
spot
over
here?
F
So,
first
probably
you
know
I
think
we
need
to
think
about
what
well
what's
the
criteria
to
for
the
group
I
mean
to
make
a
decision
on
what
goes
into
the
official
spec
and
what
goes
into
the
non
official
extension.
Is
that
I'm
not
sure
with
otherwise
clear
it's
on
the
same
page
as
to
that
criteria?.
B
F
E
So
so
the
question
is
really
a
list
of
mechanisms
that
we
have
in
place
today.
I
think.
Ultimately,
the
question
is
whether
you're
it
the
one
that
you're
using
in
your
example,
is
always
the
room
and
the
floor
and
like
the
building
example
right,
whether
those
the
room
and
the
floor
are
extension
and
whether
they're
not
and
I
think
so.
I've
been
I've
been
thinking
about
this
a
bit
and
they
actually
commented
on.
E
Your
also
commented
on
your
PR
and
I'm
coming
to
a
similar
conclusion
that
Doug
comes
to
I,
think
and
that
is
that
your
correlation
bag
more
or
less,
already
exists.
If
you,
if
you,
if
you
allow
yourself
to
say
the
room
and
the
floor
and
the
building
are
really
extension
to
the
event
format,
and
if
you
allow
them
to
be
at
the
outer
level
of
the
events,
then
you
don't
need
to
have
that
extra
bag,
which
means
your
correlation
properties.
E
Bag
per
se
is
already
existing
because
we
allow
arbitrary
extensibility
on
the
event
per
se,
and
what
we
need
is
a
set
of
rules
to
effectively
deal
with
potential
collisions,
but
we
can
go
in
and
use
the
event
in
a
way
that
we
say
you
can
do.
You
could
put
whatever
you
like
on
to
that
event,
and
the
only
thing
that
the
only
thing
we're
concerned
about
is
future
collisions.
E
The
future
collisions
can
only
and
ultimately-
and
ultimately,
what's
important
to
note
here-
and
this
is
this
is
something
to
to
internalize-
is
that
the
only
party
that
can
ever
create
collisions
is
the
publisher.
So
the
publisher
creates
an
event,
and
the
publisher
basically
sets
all
the
properties
on
the
event
and
the
event
flows,
and
and
if
the
publisher
doesn't
see
any
business,
see
any
collision
risk,
which
means
it
takes
the
standard
cloud
events
properties
and
then,
as
in
a
room
and
floor
and
building
that's
fine,
and
then
it's
just
up
to
the
receiver.
E
Now
there
difference
here
and
that's
also
something
I
talked
about
with
Doug
separately
for
cases
where
you
have
an
external
standard
that
you
need
to
adhere
to,
like
you,
have
a
set
of
properties
that
are
defined
from
some
from
somewhere
on
the
outside,
like
I'll
pick
OPC
UA
as
a
standard,
and
it
can
go
all
amazin
ml,
you
can
kind
of
use
any
any
sort
of
existing
Center
and
let's
say
they
are
defining
a
source
or
finding
a
property.
That's
colliding,
then,
with
the
mapping
rules.
E
We
already
have
in
place
the
one
thing
that
has
been
accepted
already
in
the
HCP
spec,
but
yesterday
we
actually
have
a
mechanism
place
where
you
can
go
and
add
a
property.
Let's
say
that
call
that
OPC
UA,
where
you
can
go
and
put
all
the
OPC
you
properly
properly,
obviously
away
properties
into
a
bag,
and
they
get
sterilized
appropriately
into
transports
and
they
get
included
as
a
bag
into
serialization.
E
But
it's
a
top-level
extension
and
it's
a
tough
labor
section
where
you
can
go
and
avoid
any
clashes
with
the
existing
Khalidov
in
schema
by
sticking
them
into
the
back.
But
you
can
do
this
today
with
the
mechanisms
that
we
have
in
this
today
without
having
an
extra
property
bag,
which
means
the
requirement
that
you
have
by
adding
extensibility
items
that
you
need
for
correlation.
It's
already
satisfied
with
respect
per
se
as
we
have
it.
If
we
say
we
are
allowing
arbitrary
top-level
accessibility.
F
F
So
tremendous
the
duty
member
number
it
just
example,
so
I
am
not
sure
whether
that
that's
a
little
misleading
or
not.
It's
just
example.
It
could
be
a
travel
request,
ID
yeah,
it
could
be
okay
though
it
could
be,
you
know
so,
but
for
a
specific
event
sauce,
it
won't
be.
It
will
not
be
you
know
a
lot.
It
would
be
just
one
or
maybe
two
or
three,
but
you
know
because
a
different
event.
F
Correlation
label,
or
we
call
we
quit
identification
label-
could
be
different.
So
so
that's
why
I
think
you
know
it's
good
to
put
into
a
bag,
because
I
don't
think
why
you
know
I
why
this
bag
becomes
such
a
easy,
because
this
bike
is
clearly
defined.
It's
not
like
just
say,
a
very
generic
generic
bag.
So.
B
Let
me
jump
in
here
and
I.
Apologize
I
should
have
acted,
something
a
lot
sooner.
I
didn't
want
to
say,
discuss
your
particular
PR.
Yet
I
was
hoping
to
discuss
the
broader
issue
of
extensions
and
I
apologize.
We
kind
of
got
a
little
bit
off
track,
but
then
I
realized
we're
running
out
of
time
anyway.
B
So
I
said
let
it
go
since
we're
not
gonna,
probably
be
able
to
have
the
time
to
do
the
deep
dive
into
extensions
in
general,
so
I,
because
I
don't
think
we
have
time
right
now
to
talk
about
either
issue
I'd
almost
rather
not
start
and
run
the
risk
of
running
over
time
and
people.
You
know
be
late
for
the
next
meetings.
Yeah.
B
Right,
so
let
me
do
this
so
I
put
this
document
out
here
for
people
to
put
comments
on
to
give
their
opinion
like
Rachel's
done
just
did
on
here.
So
please
go
through
this
particular
Google.
Doc.
Add
your
opinion
about
whether
those
particularly
use
cases
relative
to
extensions
in
general
are
ones
that
you'd
like
to
see
a
support
or
not
Kathy
I've
I
think
get
together
with
you
probably
next
week,
because
I'll
be
on
the
west
coast,
so
timewise
we
should
be
able
to
sync
up
much
better
than
we
were
able
to
this
week.
B
They
have
a
more
in-depth
discussion
offline
about
your
PR
if
possible,
and
maybe
I'd
like
to
at
least
have
you
understand
better-
why
there
are
concerns
and
then
we'll
try
to
revisit
this
again
on
next
week's
call.
Is
that
okay
with
people,
because
I
don't
think
we
have
time
right
now
to
deep
dive
on
any
of
this
stuff?
H
B
H
E
B
Excellent
and
I'm
back
to
Clinton
Reeves.
Are
you
there?
Alright?
Is
there
anybody
I
missed
on
the
roll
call?
Ok,
so
please
homework
assignments,
please
make
sure
you
review.
Clements
peel
are
for
the
bar.
There
can
be
setting
for
allowing
new
specifications
into
our
group.
The
extensions
Yusuke
stock
I
like
to
get
some
feedback
on
that
and
I
believe
those
are
two
hungry
signs.
Oh
review
the
logo
and
comment
on
that
in
Austin
and
I.
Think
it's
an
issue,
not
a
PR.
Please
comment
on
that.
If
you
have
any
feedback
on
that,
one
I'm
gonna.