►
From YouTube: CNCF Serverless WG Meeting - 2018-12-06
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
Alright,
three
up
today:
why
don't
we
go
ahead
and
get
started?
I,
don't
believe,
there's
anything
exciting
to
mention
on
the
a
eyes.
So,
just
a
reminder,
we
decided
to
cancel.
Obviously
next
week's
phone
call
due
to
coop
con
and
then
after
that,
people
gonna
start
taking
vacations,
so
I
decided
to
cancel
basically
the
rest
of
the
meetings
for
the
year
and
I
would
believe.
We
agreed
to
start
back
up
again
on
January
10th,
so
everybody
have
nice
vacations,
see
you
back
then
cater
time.
A
All
right
moving
forward,
then
all
right,
SDK
work
Austin
since
you're
hoping
to
be
able
to
join
the
call
there
I'll
try
to
get
the
status
the
best
as
I
remember.
We
have
been
having
weekly
phone
calls
everybody's
been
going
through
the
process
of
upgrading
their
SDK
code,
support
0.2,
with
the
assumption
that
the
vote
was
gonna
pass,
plus
putting
the
version
number
0.1,
it's
just
flat
wrong,
given
the
state
of
thing
so
everybody's
been
upgrading,
we
are
planning
on
calling
it
alpha.
A
We
also
noticed
that
there
was
no
governance
documentation
in
our
SDKs,
yet
so
I'm
going
to
agree
to
think
the
first
pass.
It
writing
that
up
as
of
right
now,
the
general
plan
is
to
have
the
governance
stock
be
shared
in
the
main
repo
meaning,
the
spec
repo
under
SDK
directory.
That
way,
we
don't
the
duplicated
in
every
single
SDK.
A
Each
SDK
will
have
its
own
equivalent
of
an
owner's
file
right,
so
list
of
maintain
is
maybe
different
per
SDK,
but
at
least
then
the
governance
stocks
should
be
consistent
across
all
of
them,
but
we
are
going
to
leave
the
door
open
for
a
particular
CK
to
tweak
the
the
governance
if
they
need
to
so
bulges
provide
a
baseline,
but
then
they
can
augmented
slightly
if
they
wanted
for
some
reason
what
they
want
to
change.
It
isn't
simply
additive
and
they
actually
want
to
change
something
the
base.
A
A
A
A
That's
meant
to
be
sort
of
a
guide
for
all
the
SDKs
so
that
they
can
sort
of
have
the
same,
look
and
feel
as
best
they
can,
even
though
there
will
be
language,
specific
differences,
but
we
wanted
to
try
to
get
them
to
have
similar
functionality
at
a
high
level,
or
you
know,
like
I,
said,
busily
good.
The
same
look
and
feel
so
yeah.
C
C
Makes
sense
and
on
our
companies
and
we're
still
strongly
committed
to
this,
and
we
have
like
a
handful
of
releases
that
we're
trying
to
get
at
the
door
that
involve
cloud
events
we're
just
taking
taking
our
sweet
time
trying
to
get
it
right.
So
we
hopefully
have
some
cool
stuff
to
announce.
Oh
cloud
events
early
next
year,
excellent.
A
A
Right,
thank
you,
koukin
all
right,
so
the
slides
are
there.
I
did
I
could
take
the
Shanghai
ones
and
convert
them
over
to
use
the
Seattle
template
I've
been
updating
my
version
or
might
the
size
that
I
was
going
to
talk
to
Kathy
and
Clements
I.
Don't
think
they've
got
anything
or
Harvard.
Then
I
started
that
yet,
but
I
expect
that
to
happen
really
soon.
In
fact,
we
have
a
phone
call
right
after
this
to
talk
about
the
progress
on
that,
but
anybody
else
on
the
call
please
feel
free
to
review.
A
What's
there
if
you
have
any
comments,
I
suspect
there
probably
won't
be
a
whole
lot
of
changes
from
what
was
in
Shanghai.
Send.
It
obviously
was
only
a
couple
weeks
ago,
but
if
you
think
that
something
does
need
to
change
for
this
audience,
please
let
us
know
and
the
link
to
it
is
right
here:
okay,
any
questions
or
comments
for
anybody
all
right
demo.
We
are
planning
on
showing
this
at
the
coop
con
next
week.
It's
not
too
late
to
add
your
endpoint.
A
If
you
do
want
to
add
one
I
believe
right
now
we
have
about
seven
or
eight
or
something
like
that.
I
think
one
more
company
is
planning
on
doing
it.
It
doesn't
take
a
whole
lot
for
me
to
add
it,
so
we
I
can
add
it.
You
know
pretty
quickly
up
to
the
date,
the
only
constraint
I
have
is
I
do
have
a
chart
that
that
lists
out
all
the
various
companies
there,
so
I
may
have
to
start
shrinking
things
and
we
get
too
many
more
people.
But
that's
that's
not
a
concern.
A
I'd
rather
add
your
endpoint,
then
we're
out
the
truck
the
slide
later.
So,
if
you
do
want
to
add
an
endpoint
this,
please
let
me
know
the
this
design
doc
here.
It's
all
you
need
be
all
you
need
to
know.
If
you
want
out
and
then
point
it's
relatively
straightforward,
didn't
pretty
much
just
a
random
number
picker
for
more
than
anything
else,
all
right,
any
other
questions
or
comment
on
that
alright
cool
moving
forward
all
right
before
we
get
into
the
other
PRS.
We
have
a
vote
on
0.2
release.
A
I
will
go
through
and
do
the
voting
in
a
second.
There
was
a
comment
from
somebody,
though
Nathan
Dennis,
that
he
was
hoping
to
get
this
cloud
events,
SDK
spec,
repose
old
merged
into
0.2.
Since
we're
going
to
be
kind
of
advertising
the
SDK
work
at
coupon,
he
thought
it
might
be
good
to
have
that
as
merged
into
the
merge
eight
had
that
they
are
merged
in
time.
A
Technically,
the
vote
did
not
include
that,
obviously,
because
the
PR
are
still
pending.
However,
that
document
is
non-normative.
It
doesn't
touch
our
spec
whatsoever,
it's
strictly
additive,
so
what
I
wanted
to
do
was
to
get
a
sense
from
the
group,
whether
you
guys
would
be
okay
with
with
considering
adopting
that
PR
and
sliding
it
into
the
zero
point
to
release
or
whether
you
guys
want
to
be
a
stickler
for
the
process
and
say
no.
The
vote
did
not
include
it.
A
E
A
Okay,
so
tell
you
what,
let's
just
not,
it
was
actually
the
Mathis
question.
Is
there
any
objection
to
considering
this
PR
for
merging
into
0.2?
Why
there's
still
gonna
be
the
question
of
whether
we
actually
want
to
merge
the
PR
itself,
because
whether
it's
good
enough
but
I
wanted
I'm
just
asking
whether
whether
there's
any
objection
to
even
considering
it
for
0.2
at
this
time?
A
D
Have
not
got
chance
to
look
at
this,
yes
good.
We
have
a
few
days
to
Marsha's
before
well,.
A
F
A
Sounds
nice
I'm
just
trying
to
think
about
the
process
here?
Cuz
asynchronous
votes
are
technically
supposed
to
take
a
week
which
I
think
is
you're
problematic
for
coop
con
and
get
him
people
getting
ready
for
coop
going
on
I'm,
just
not
sure
just
what
a
process
perspective
I'm
not
quite
sure
how
to
how
to
out
here
to
what
we've
done
it
was
agreed
to
that's.
My
only
concern
yeah.
E
That's
what
I
was
trying
to
say:
Doug
I
think
it's
it
may
be.
We
may
be
rushing
things
if
we
try
to
merge
it
before.
We
declare
point
two,
but
I
think
it
would
be.
It
would
be
good
to
at
least
mention
in
point
two
that
there
is
the
SDK
coming
and
maybe
leave
the
PR
on
merge
for
now.
Well,
we're
definitely
well
okay.
When.
E
F
B
A
B
C
I
feel
comfortable.
Just
putting
this
out
there
definitely
chatting
with
lots
of
customers
and
users
every
single
day
and
I'm
just
dying
for
something
that
I
could
give
them.
That
actually
makes
this
specification
accessible,
so
they
could
start
using
it
in
their
projects
and
stuff
and
I
know
as
soon
as
we
have
something
we'll
start
getting
a
lot
of
valuable
feedback
and
be
able
to
make
more
informed
product
decisions.
C
A
In
mind,
this
is
just
a
draft
document
that
pretty
much
everything
in
our
in
our
repo
right
and
if,
as
I
said,
it's
completely
non
normative,
doesn't
force
anybody
to
do
anything.
It
doesn't
even
technically
force
the
SDK
writers
because
it
they
haven't
actually
firmly
you
know
I
could
proved
as
much
other
than
it's
just
a
draft.
A
Okay,
not
hearing
anything
okay.
So
now,
let's
go
back
to
the
vote
and
to
be
perfectly
clear,
the
0.2
vote
is
based
upon
the
spec.
After
last
week's
phone
call
with
all
the
peers
that
we
approved
last
week
merged
Plus.
Now
it's
going
to
include
this
additional
document
from
Dennis
and
when
I
do
my
release
notes
know
best.
I
did
I'm
sorry
I'm,
look
at
the.
A
And
here
the
release
notes,
I'm
gonna
include
I,
tried
to
include
everything.
I
could
think
of
that
was
relatively
large
okay,
so
we
had
some
people
already
starting
to
vote.
I
will
actually
ask
the
people
who
voted
yes
before,
just
to
make
sure
they're
not
going
to
change
their
mind
based
upon
this
of
the
PR
that
we
merged
just
to
be
perfectly
safe
in
terms
of
voting
roberto
or
I'm
sorry.
Adobe.
Do
you
want
to
change
your
vote.
A
H
A
F
F
A
G
J
A
A
Right,
Vlad,
you
still
yes,
I'm
stealing
this
okay
and
what
about
tippy
knee
all
right,
so
we
did
I
miss
anybody.
We
can
say
I'm
voting
rights,
all
right.
We
have
12
yeses,
no
no's
and
there's
one
abstain,
which
text
I
said
no
vote,
so
the
vote
passes.
Thank
you
guys.
Very
much
I
will
do
the
exciting
process
of
getting
it
out
there
all
right
this
one's
approved
all
right
next
on
the
agenda
rocket.
Actually,
that's
a
question
for
release
in
0.2,
I'm.
Obviously,
gonna
merge
the
PR,
create
the
release
and
stuff
like
that.
A
M
A
A
Out
I
had
not
I,
don't
have
one
planned,
I
was
probably
gonna.
Do
one,
but
I
haven't
started
anything
I
already
tweeted
before
you
asked.
I
N
A
A
A
O
A
Technically,
I
guess
as
long
as
it's
out
there
before
our
first
session,
which
is
the
intro,
but
to
be
honest,
if
we
could
get
the
blog
out
there
before
the
keynotes,
we
may
be
able
to
harm
to
us
somebody
who's
a
keynote
to
mention
it
as
well,
because
I
know
Dan
and
Chris
have
done
in
the
past
for
us.
So
that's
why
I
wanted
I
think
it's
best
to
say,
I
think
it's
best
to
assume.
We
went
out
there
before
coop
Don.
A
O
O
A
L
I
That's
what
we
were
right
now.
It
means
I'm.
In
the
meantime,
obviously
there
would
have
been
some
additional
conversations,
but
I
think
they've
they've
they've
changed
any
of
that.
Okay,
so
for
me
the
yardstick
is:
doesn't
help
interoperability
amongst
multiple
product
of
products
and
projects.
If
we
add
this
finding-
and
the
answer
here
is
very
clearly
no
because
nobody
would
read
that
spec,
except
for
the
market,
if
you
and
cutie.
A
F
Don't
feel
like
I
know
enough
about
what
the
standard
and
the
default
standards
are,
especially
in
China
like
that's
the
part
that
gets
my
attention
to
say
that
it
does
not,
and
I
would
rather
skew
on
the
side
of
letting
more
things
and
rather
than
being
overly
restrictive.
Here,
that's
my
that's
my
first
impulse.
Okay,.
I
The
metric
is
how
many
implementations
are
there
and
I?
Don't
know
any
and
haven't
seen
any
and
and
I
understand
that
the
the
product
may
be
use
in
China
a
lot,
but
that
doesn't
mean
anything
if
a
lot
of
customers
are
using
sorry
Doug,
IBM
MQ,
which
has
a
closed
protocol.
That
doesn't
mean
anything
for
interoperability,
because
it
has
a
closed
protocol
and
it's
a
for
me.
The
yardstick
is,
do
do
we
do
because
we
do
we
do
protocol
bindings,
we
don't
do
product
bindings
and
this
is
a
product
binding.
I
I
I
It's
also
about
implementation,
matrix
right,
I
know:
I
went
in
mr.
Sharpe
SDK.
This
new
person
is
female,
supported
and
an
HTP,
and
when
I
can
I'll
also
support
maths
right.
Other
people
are
writing
the
SDKs
for
Goa
cetera,
et
cetera,
every
single
additional
protocol
protocol
and
and
product
binding.
We
add,
multiplies
the
maintenance
effort
in
the
implementation
effort
in
every
runtime
in
language.
Binding
I
would
much
rather
prefer
for
us
to
say
here.
I
Are
the
protocols
for
particular
pillars,
use
these
pillars
that
we
know
and
we're
actually
pretty
well
set
up
for
that,
because
there's
not
a
ton
of
overlap
between
the
ones
that
we
have
and
really
bet
on
those
and
double
down
on
those
and
be
principal
principal.
Both
of
them
keep
the
complexity
of
our
implementation
matrix
or
the
SDK
down,
rather
than
be
happy
to
invite
every
product
to
go
on
and
call
events
binding.
What
we
then
on
the
SDK
side
have
to
go
and
support
get
another
one
and
get
another
one
and
another
one.
I
A
M
You
know
what
was
being
said
resonated
with
me
as
well,
in
terms
of
trying
to
create
an
inclusive
community,
where
we
want
this
to
be
widely
adopted
as
a
standard.
What
you
know
what,
if
their
team,
has
so
much
impetus
that
they
want
to
create
this
spec
and
don't
you
know,
contribute
it
and
actually
maintain
it?
How
much
you
know
how
much
of
a
burden
is
it
for
us
if
we
exclude
them,
could
this
be
a
like
an
alfa
spec?
M
A
Okay,
thank
you.
Alex
somebody
hands
up
next
I
wanted
to
get
people's
thoughts,
I
guess
in
particular,
clemens
your
thoughts
on
that
paragraph
or
sentence
that
I
have
highlighted
because
it
basically
it
says
we
would
like
to
see
at
least
one
open-source
implementation
and
at
least
a
dozen
independent
vendors
using
it
I
believe
they
meet
that
criteria,
don't
they
because
they
have
one
implementation
and
according
to
them,
they
have.
A
You
know
hundreds
of
companies
using
it,
but
I
think
satisfies
that
at
least
a
dozen
independent
vendors
using
it
so
I'm
trying
to
understand
from
a
strictly
process
perspective.
Do
they
not
meet
the
criteria
in
the
second
bullet
I?
Guess
that
questions
more
for
Clemens
and
I'll
I'll?
Stick
you
implicitly
into
the
Q
comments,
but
a
lot
of
let
Rachel
go
so
I
think
he
had
her
hand
up
next.
F
Okay,
Michael,
that
was
I,
totally
understand
the
need
to
keep
a
to
minimize
the
burden
on
the
people
who
are
developing
the
SDK
I'm
sympathetic
to
that
I
suspect
that
the
people
who
are
willing
to
propose
the
spec
are
probably
willing
to
help
out
with
some
of
that
work.
I
don't
know
if
that
will
be
true
for
sure,
and
then
the
other
point
that
I
would
like
to
say
is
like
a
larger
point,
which
is.
This
is
a
very
young
spec
like
that.
F
I
feel
like
there's
a
greater
risk
that
we
will
spend
a
lot
of
time.
Building
this
and
no
one
will
ever
use
it.
Then
there
is
that
then,
like
we
spend
a
lot
of
time
building
this,
and
now
we
have
too
much
work
to
maintain
it
for
all
the
people
that
want
to
use
it.
So,
like
my
bias,
right
now
would
be
if
someone
is
excited
to
use
it
and
wants
to
propose
I'm,
not
saying
we
should
accept
every
speck
that
comes
in
I'm,
saying
like
our
like.
A
I
I
Now
you
can
go
in
and,
and
it
shows
up,
it
shows
up
nowhere
where
I
can
see,
and
it
might
be
a
function
of
me
not
being
being
able
to
see
behind
the
Great
Firewall
of
China
I'll
admit
that,
but
I
again,
I
only
see
one
implementation
of
that
and
then
is
like,
of
course
practically.
We
would
like
to
see
at
least
one
open
sort
of
invitation
under
the
umbrella
and
at
least
independent
vendors,
using
it
I
think
I.
I
Think
of
that
team
together
as
something
that
if
it's
Kafka,
because
it
is
a
de
facto
standard
in
its
category
like
everybody,
is
using
that
thing
and
there's
one
implementation
of
it,
but
I,
don't
think
of
rocket
and
Q
being
at
the
same.
At
that
same
level
right,
everybody
knows
Kafka,
but
probably
most
of
you
didn't
know
rocket
in
Cuba
for
Alibaba
proposed
by
D.
So
that's
neat,
so
that's
my
estimate
again.
I'm,
not
the
I'm
not
vehemently
against
it
because
of
where
it
comes
from
I,
just
I,
just
think
it
doesn't.
I
P
A
couple
of
quick
things:
I
agree
with
Clement
totally
quick
point.
Our
company
solises,
I
bypass
tip,
go
as
far
as
messaging
implementation,
so
just
want
to
throw
that
out.
However,
one
important
thing
is:
we
already
have
the
JSON
payload.
That
is
a
way
to
implement
it
if
you
are
doing
something
proprietary.
So
it's
not
that
there's
nothing.
P
However,
I
almost
like
to
suggest
that
we
have
a
generic
protocol
binding
where,
as
long
as
you
have
a
capability
within
your
messaging
API
to
do
a
user
definable
header
which
is
being
used
right
now
with
a
protocol
bindings,
that
would
definitely
motivate
companies
such
as
ours
to
wipe
our
own
or
our
proprietary
api's.
Our
own
protocol
bindings.
As
long
as
there
was
a
spec
for
a
generic
protocol,
bind
so
I'm
wondering
if
that
might
be
an
option
to
get
get
more
deployment
and
more
interest
than
but
again
I
agree.
P
P
Right
now,
if
you
look
at
how
we
do
the
AMQP
or
the
rest
or
even
the
mqtt,
what
we've
just
what
it
appears
has
been
defined.
Is
you
create
user
definable
protocol
headers,
where
you're
defining
name
value
pairs,
where
you
specify
what
is
the
label
going
to
be,
which
is
slightly
different
for
an
QP
versus
and
Q
versus
rest,
and
then
you
define
what
is
the
actual
values
and
their
castings?
That
string
is
an
integer
or
whatever,
but
there
is
a
different
one
where
Clemens
has
done
a
good
job.
P
However,
that
doesn't
mean
that
we
can't
maybe
generate
the
generic
one
where
we
have
this
is
you
know
a
common
set
of
name
value
pairs
and
casting
for
the
values,
what
those
definitions
mean,
and
if
you
support
user
extensible
headers,
then
you
should
be
able
to
write
your
own
protocol
binding
for
your
own
products
and
if
there
is
an
interoperability,
so,
for
example,
I
look
at
solace
or
if
it
comes
in
as
one
of
our
proprietary,
we
can
go
out
and
QP
or
rest
and
do
that.
Vice
versa.
P
That
means
our
clients
that
want
to
use
special
functions
that
we
have
in
our
broker
that
are
beyond
what
the
specs
have.
It
allows
us
to
still
do
those
bindings
and
still
interoperate.
It's
mapped
through
our
our
products,
but
also
our
gateways
and
everything
else.
So
not
you
know
not.
Every
protocol
binding
should
necessarily
be
part
of
the
API
that
you
know
the
group
has
to
worry
about
some
cases.
The
vendors
will
probably
be
interested
in
doing
that
adoption,
but
for
that
you
would
need
a
generic
protocol
binding
that
make
sure
it.
A
K
Sorry,
yeah
I'm,
not
speaking
on
mute
and
yeah
I
I,
think
this
comes
back
to
the
standards
question
and
I
would
be
more
in
favor
of
doing
something
in
terms
of
the
openness
Jing
speck.
But
having
looked
at
that,
that
speck
is
very
Java
centric
at
the
moment,
even
though
it
claims
that
there's
other
language
supports
so
I
don't
know
if,
if
that
binding
could
be
recast
in
terms
of
open
messaging,
I
know
I,
don't
that
would
address
some
of
the
previous
gentleman's
comments
as
well.
K
I
mean
if
there
was
an
open
messaging
to
solace
binding
then
you
know
that
would
then
just
naturally
sort
of
fall
through
I.
That
was
my
assumption.
I
did
under
one
side,
these
people
are
saying
rocky
and
Q
is
very
widely
used
and,
on
the
other
hand,
they're
saying
it's
the
first
implementation
of
open
messaging
so
I
that
that
was
my
angle
to
try
and
recast
it
in
terms
of
the
other
spec.
Okay,.
F
I
The
reason
why
we
rejected
is
is
because
open
messaging,
literally
listed
takes
from
us
and
and
the
open
message
you
expect
is
exactly
at
the
same
level
of
way
of
where
we
are
here.
With
this
project
we're
doing
eventing
and
the
open
messaging
spec
is
effectively
trying
to
do
something
that
is
very,
very
similar
for
for
messaging,
which
means
it
has
kind
of
more
elements
of
reply
to
and
to
and
kind
of,
addressing
them
and
depressing
elements
cetera.
But
it's
hard
to
not
the
abstraction
that
we
hear
on
the
instruction
and
of
the
messaging
provides.
A
So
in
terms
of
moving
forward
here,
I'm,
so
part
of
me
is
sort
of
jumping
to
a
conclusion
that
says:
there's
a
very
boolean
choice
in
front
of
us,
basically,
yes
or
no,
but
before
we
head
down
that
path.
Can
anybody
see
an
option
here
where
there's
some
way
to
morph
this
PR
into
something
that
may
be
acceptable
to
the
group?
Or
does
it
really
just
come
down
to
yes
or
no?
Do
we
want
rocket
MQ
yeah.
A
Yeah
yeah,
that
is
true,
do
do
people
think
that
we
should
revisit
that
decision
or
die
well.
Is
that
an
option
that
people
want
to
consider?
Put
it
that
way
and
something
like
you
know,
you
don't
fit
a
semi
criticism
right
now,
because
I'm
not
going
to
I'm,
not
even
gonna,
propose
that
we
close
this
pull
request,
even
if
everybody
voted
no
right
yet
because
I
do
want
to
give
a
people
more
time
to
think
about
it.
But
what
do
people
think
about
revisiting
the
Yoakum
messaging
decision?
What.
K
No
such
heroic
investor,
your
honor
I,
think
the
other
issue
here
is
that
if
we
keep
cutting
people
off,
then
that
could
leave
a
bad
taste
in
people's
mouths.
Even
though
it's
well-intentioned
is
there
another
angle
where,
where
we
could
say,
okay
will
host
your
binding
specification,
but
we
won't
manage
it.
So
you
become
a
central
repository
for
proprietary
bindings,
but
you
do
it
on
the
understanding,
though
the
vendors
that
publish
that
are
responsible
for
maintaining
it
and
it
and
it
doesn't
fall
to
us,
but
we
become
a
librarian
more.
K
I
So
if
we
make,
if
we
think,
that's
a
good
idea,
so
if
we
made
a
folder
and
it's
called
projects
or
our
products
of
some
sort,
you
can
say
you
here's
a
document
that
you
own
and
you
can
go
and
put
that
there
and
because
you
have
a
protocol,
that's
not
that's,
not
meeting
our
criteria,
but
you
still
want
to
provide
visibility
for
how
that
maps
to
your
product.
I.
Don't
think!
That's
I,
don't
think!
That's!
That's
terrible!
It's
just
a
question
of
you
know.
I
M
M
That
sounds
like
something
that
could
help
with
some
of
the
objections
we
had
about
the
being,
perhaps
to
you
exclusive
or
to
my
part,
and
it
would
remind
me
of
something
like
the
the
landscape
in
the
scenes.
Yet
there's
projects
that
are
listed
there
aren't
necessarily
donated
yet
there
might
be
in
future,
and
it
kind
of
has
a
parallel
with
that.
A
P
P
This
is
exactly
what
a
lot
of
vendors
have
done,
and
it's
this
idea
of
a
catalog
or
a
repository
is
an
excellent
suggestion
where,
if
you
did
have
a
generic
binding
leave
it
to
the
vendors
to
do
the
bindings,
which
we've
done
multiple
times
for
other.
You
know
payload
and
protocol
standard
things,
and
you
know
you
would
be
able
to
get
the
links
into
you
know
for
the
weblink,
those
peers,
other
vendors,
there
probably
be
more
people
interested
in
participating.
It
would
help
in
interoperability.
I
think
it
would
be
quite
valuable.
Q
Q
If
you
pass
this
suite
of
whatever
compatibility
test,
then
you
get
this
stamped
and
if
you
don't
right,
that's
a
different
level
of
you
know
that
that
lack
of
interoperability
right
so
that
somebody
looking
as
a
user
right
as
a
customer
of
this
one
of
the
problems
with
these
kind
of
open
repositories,
is
they
end
up
being
a
dumping
ground
right
so
that
some
vendor
can
get
a
checkmark
and
claim
you
know,
claim
halo
status?
We
support
all
these
open
standards,
but
they
don't
really
right,
which
I
think
is
part
of
Clements
concerns.
A
K
Just
very
quickly
I
don't
need
to
drop
off.
Unfortunately,
I.
Maybe
there's
a
way
to
use
this
as
a
almost
like
a
pathway
to
a
first
class
support,
so
like
rocky,
and
you
may
elevate
itself
to
an
open
messaging.
You
know
compliant
thing
as
when
that
becomes
more
widely
available,
but
it
but
I
do
I
agree
that
there's
a
flip
side
to
this
with
the
dumping
ground
and
you
know,
setting
more
standards
around.
You
know
what
you
need
to
do
to
meet
the
bar,
so
I
think
it
deserves
more
discussion.
Okay,.
D
I
think
I
agree
with
that.
You
know
I
think
if
we
do
not
have
what
was
the
purpose
of
this,
we
would
to
promote
interoperability
right.
If
you
know,
if
some
particle
cannot
meet
that
standard,
then
it
is
just
like
a
dumping
ground.
A
Ok,
ok,
so
it
seems
like
there.
There
may
be
enough
people
on
the
call
to
warrant
somebody
writing
up
a
proposal
for
us
to
consider
having
there's
sort
of
another
tier
of
transport,
binding
specification,
similar
to
our
documented
extensions
stuff
that
we
have
is
there
somebody
he'd
be
willing
to
write
up
that
pull
request
to
put
the
proposal
out
there.
I.
A
A
A
A
A
A
Missed
on
my
first
day,
weird
I,
don't
know
why
I
did
that
I
usually
spell
it
right.
Maybe
it's
the
Google
Google.
Yes,.
A
M
A
A
M
A
You
have
to
jump
through
and
that's
gonna
really
muck
with
their
logic
in
terms
of
how
the
bubbles
flow
and
stuff
like
that,
I
can
ask
him
to
take
a
look
at
it,
but,
to
be
honest,
I
didn't
think
it
was
critical
enough
to
pull
him
off
of
other
work
to
work
to
fix
that
relatively
minor
issue.
But
it
is
just
a
Mac
specific
issue.
To
be
honest,
is
what
I
mean.
A
A
A
M
A
Yeah
that'd
be
great.
Like
I
said
it's
not
a
big
deal
for
me
to
add
it.
Just
you
know
the
URL
and
and
I
need
the
URL
to
the
endpoint
and
a
URL
to
what
logo
you
want
displayed.
That's
only
two
sets
of
criteria.
Okay,
yeah.
A
Okay,
in
that
case,
funnel
roll
call,
I
heard
Kathy
Richard
ferati
there,
oh
yeah
excellent
Joe,
Scherman
Joe
did
you
Ben
had
Jimmy
Adventist
favio,
oh
yeah
I'm
in
here,
okay
did
I
miss
anybody
else
on
the
roll
call.
A
N
A
What
about
oh
I'm?
Sorry,
Iago!
Are
you
there
I
just
noticed
that
name
in
there
ya
go
okay,
I,
don't
hear
him
all
right
cool
any
my
case,
I
believe
we
were
done
and
we'll
see
if
turnover
you
guys
next
week.
If
not,
everybody
have
a
good
vacation
and
we'll
talk
again,
January
10th.
That
believes
the
next
call.