►
From YouTube: CNCF Serverless WG 2021-03-04
Description
CNCF Serverless WG 2021-03-04
A
Hey
good
morning,
hello,
let
me
just
get
set
up
here.
We
have
a
quick
question
for
you.
I
wanna
I'm
switching
companies.
How
do
I
do
that
with
cncf
or
lead
this
group
in
terms
of
affiliation.
B
Basically,
from
my
perspective,
it
just
tell
me
and
I'll
switch
it
I'll.
Just
move
you
in
the
spreadsheet
and
that's
about
it.
A
Okay,
all
right
I'll
do
that
afterwards,
cool!
Thank
you
yeah,
and
the
enter
off
stuff,
we're
doing
demos
at
the
end
of
the
month.
Is
that
right?
We
are
hoping
okay,
I
I
have
next
week
off,
so
I'm
actually
going
to
take
a
few
days
and
just
try
to
plug
it
through
and
get
something
set
up.
I
just
wanted
to
double
check
my
timing
in
terms
of
where
things
are
going
to
be
set
up
and
that
helps.
B
B
Yeah
end
of
march,
and
then
hopefully
maybe
I
could
come
actually
have
a
demo
or
we're
going
to
start
into
march.
So
yeah
you're
right,
okay,
perfect
that
works
out.
Thank
you.
Cool
that'd
be
exciting.
I
know
everybody
has
been
wanting
to
find
time
to
do
stuff.
It's
just
nobody
seems
to
be
able
to
find
it
so
well.
A
I
have
a
week
off
so
it
gives
me
some
time
to
get
caught
up
again.
It's
kind.
D
B
A
Not
sure
I've
heard
of
them
cyber
security
endpoint
most
of.
A
Most
of
their
work
is
actually
in
serverless
space,
oh
cool,
but
they
do
endpoint
security,
mostly
cloud
focus
serverless
all
their
apps
are
serverless.
So
when
I
go
there,
one
of
the
things
that
I'll
start
for
another
week
and
a
half
or
so,
but
one
of
the
things
that
we'll
end
up
doing,
is
trying
to
roll
over
into
doing
an
integration
with
this
project.
A
B
A
It's
both
I've
been
at
several
different
companies
and
each
place
I've
been
at
the
culture
how
they
operate.
Things
is
completely
different
and
you
experience
both
to
be
honest,
some
cases
it's
like
wow,
I
love
it.
This
is
the
best
thing
I've
ever
done
in
other
cases,
it's
you're
like
what
you
know.
What
did
I
miss?
You
know.
I
don't
see
how
I
missed
this
beforehand
and
it
really
depends.
So
you
know
it's
and
ibm
that's
a
long
time
by
the
way,
which
is.
B
A
very
long
time,
yes,
I
won't
tell
you
exactly
how
many,
but
yes,
it's
been
a
while
all
right,
let's
see
who's
on
eric.
Are
you
there.
D
B
There
you
go
in
case,
I
decide
to
try
to
make
you
speak
up
on
the
call
there
you
go.
B
I
tried
reading
through
your
latest
comment
on
the
issue
you
opened
eric
last
night.
I
I
unfortunately
I
couldn't
make
it
through
at
all
yeah.
I
had
to
say
it
for
another
day.
That
was
a
big
comment.
B
Well
then,
maybe
we
don't
have
to
talk
about
it
today.
Well,
actually
I
I
didn't
add
it
to
the
agenda,
but
if
you
want
me
to,
I
can
you
know.
B
Well,
I
was
also
really
really
tired.
It
was
late
at
night,
so
don't
don't
don't
read
too
much
into
that
all
right.
How
are
you
there
yep
all
right
and
hey
john
thanks
for
making
it
my
pleasure
all.
B
H
B
So,
as
I
was
preparing
for
the
meeting
yesterday,
I
went
through
and
found
some
issues
that
I
thought
were
worthy
of
discussion.
Obviously
this
was
just
my
take
on
it.
If
anybody
on
the
call
has
a
different
set
of
issues,
they'd
like
to
add
to
the
list,
just
let
me
know
we
can
add
them
before
or
after
in
the
middle.
It
doesn't
matter
where
they
go,
but
I
want
you
guys
to
think
that
you're
stuck
talking
about
the
ones
that
I
thought
were
interesting.
B
B
B
B
B
All
right,
three:
after
when
we
go
and
get
started,
just
let
you
know
I
know.
Last
week
we
talked
about
what
to
do
about
the
whole
branch
github
situation
and
I
didn't
hear
any
objections
to
doing
clement's
suggestion
of
just
merging
everything
into
101
branch
as
long
as
they're,
you
know
strictly
typos
type
stuff
and
lance.
I
did
see
your
comment
and
I
interpreted
your
comment.
It's
basically
saying
that's
fine,
just
let's
make
sure
we
document
it
did.
I
interpret
that
correctly.
I
B
Yeah,
okay,
okay!
Well,
I
took
from
that
to
give
myself
another
ai
to
open
up
a
pr
to
update
our
our
process,
docket
whatever
it
is,
to
make
sure
we
include
that
and
I'll
try
to
include
in
there.
The
definition
of
you
know
what's
worthy
of
being
merchant
ad
versus
forcing
us
to
go
to
102.,
okay,
and
then
you
guys
can
review
that,
but
barring
that
I
will
later
today
go
ahead
and
merge
the
pr
that
caused
me
to
even
think
about
this,
which
is
strictly
a
typographical
type
change.
B
Okay,
community
time,
anything
from
the
community.
People
want
to
bring
up.
B
All
right,
in
that
case,
sdk
call,
will
be
next
week.
This
week
we
have
interop
call
I'll
double
check.
I
don't
think
they
have
anything
on
the
agenda,
so
I
suspect
it's
more
just
a
nagging
reminder
to
everybody
to
work
on
their
code.
I
guess
we
don't
even
have
an
agenda
thing
in
here,
but
we
will
at
least
have
like
a
one
minute
phone
call
after
this
one
to
see.
B
If
there's
anybody
has
any
topics
they'd
like
to
bring
up
so
hang
on
for
that,
if
you're
interested
and
just
a
little
reminder
end
of
march
is
when
we're
planning
on
starting
the
interrupt,
and
we
are
already
in
march
so
the
pressure's
on
all
of
us.
Okay,
now
teamwork
offline
reported,
he
has
nothing
to
report
for
the
workflow
stuff,
so
we
can
keep
going
unless
anybody
has
any
questions
on
that.
B
Okay,
coupon
eu.
I
got
a
note
I
believe
last
week
asking
what
we
want
to
do.
I
could
kind
of
you
relative
to
office
hours
or
booth
or
both
does
anybody
have
any
opinion?
I'm
inclined
to
go
more
for
office
hours
because
I'm
not
sure
we
have
people
have
the
free
time
to
hang
out
at
a
booth
for
extended
periods
of
time.
But
I
wanted
to
ask
the
group
what
you
guys
thought.
B
B
All
right,
so
this
one
technically
affects
the
sdk
folks
more
than
anybody
else.
However,
I
do
want
to
draw
it
to
people's
attention
if
in
case
somebody
else
is
interested.
B
Somebody
pinged
me
offline
and
said
they're
thinking
about
offering
up
code
for
another
sdk
and,
of
course
that's
great,
but
then
I
realized
that
we
didn't
really
have
anything
in
our
governance
stock
to
describe
the
process
for
adding
new
sdks,
because
it
seemed
reasonable
to
me
that
if
the
sdk
maintainers
have
the
authority
to
vote
on
when
to
archive
a
project
when
to
get
rid
of
it
or
make
changes,
they
should
actually
have
a
say
in
adding
new
ones,
as
opposed
to
just
blindly
accepting
everything
that
comes
comes
our
way.
B
G
Is
there
an
implication,
sorry
that
the
the
list
of
initial
maintainers
on
line
18,
that
they
become
new
maintainers?
I
have
to
admit
this
is
something
I
should
have
read
this
document
a
lot
being
an
sdk
maintainer,
but
I
haven't
so.
It
may
be
covered
from
line
34
onwards
already,
but
it
feels
like
if
a
new
sdk
is
typically
because
you've
got
some
new
folks
coming
in
saying:
hey.
C
B
B
If
yeah,
if,
if
you
think
it's
unclear
I'll
I'll,
think
about
it
offline
see,
I
can
come
up
with
better
wording,
but
that
was
my
intent.
Yes,
okay,
now
we
don't,
I
mean,
obviously
you
guys
if
you
anybody
on
this
call
here,
has
a
problem
with
this.
You
know
speak
up
now
or
comment
on
the
issue
but,
like
I
said,
this
was
mainly
for
the
sdk
folks
to
to
review
and
vote
on,
but
just
wanted
to
bring
it
to
people's
attention.
E
So
doug
you
know,
since,
since
I
brought
this
up
to
you,
we
were
intending
to
not
open
source
the
library
and
then
move
it,
but
go
direct
to
cloud
events.
You
know
just
for
ease
ease
of
making
it
open
source
and
just
doing
it
once
there's
nothing
here.
That
implies
that
there's
a
review
of
the
sdk.
So
I
wanted
to
just
beg
that
question
to
the
group
to
see
whether
there
is
a
need
for
that
initial
review
of
it
before
a
vote
is
taken
because
you
don't
you
don't
explicitly
state
that
that's.
E
B
Yeah,
so
a
lot
of
other
people
speak
up,
but
my
take
on
it
is.
I
don't
think
it
should
be
a
requirement,
because
technically
someone
can
come
here
with
no
code
at
all
and
say
hey,
I
want
to
do
a
c1
right
and,
and
the
sdk
maintainers
should
be
able
to
say
yes
or
no
and
if
they
say
yes,
it's
probably
acceptable
for
them
to
start
with
a
clean
slate
and
they're
the
only
maintainers,
so
they
should
be
able
to
add
whatever
they
want
at
that
point.
B
So
it
seems
weird
that
if
you're
coming
with
code
we're
going
to
raise
the
bar
and
say
no
we're
going
to
review
your
code
first
as
opposed
to
somebody
who
has
no
code
who
gets
a
low
bar
of
just
hey.
That
sounds
like
a
good
idea.
Yeah,
that's
a
good
point,
but
that's
just
my
view.
Anybody
else
want
to
chime
in
on
mark's.
B
Point:
okay
in
that
case,
obviously,
like
I
said
just
going
to
review
it,
anybody
has
a
chance.
I
believe
the
voting
period
for
this
will
end
closes
on
monday
at
3,
4,
30
eastern.
So
if
you
are
a
maintainer,
please
vote
on
this
because
we
need
at
least
two
thirds
of
the
people.
I
say:
no,
I'm
sorry.
We
don't
need
two
thirds
of
the
maintainers
to
vote,
but
we
do
need
at
least
hopefully
more
than
just
one
person,
which
I
think
is
scott
right
now.
So.
B
G
Scotland,
I
would
be
astonished
if
there
were
currently
any
sort
of
organized
release
around
you
know
lots
of
languages
releasing
at
the
same
time
until
we've
got
something
past
1.0
it's
going
to
be
hard
to
know.
You
know
what
would
be
in
a
1.1
what
would
be
in
a
2.0
they're
going
to
that
will
affect
how
releases
need
to
happen,
because
until
we
hit
1.0
it
sort
of
didn't
matter
as
much.
G
B
Yeah,
I
think
the
answer
to
the
first
one
is:
no,
we
don't
have
it
arie
sdk
does
their
own
thing
and
dealing
with
things
being
behind.
It
depends
on
how
what
behind
means
right?
Are
they
just
slow?
We
don't
have
anything
to
talk
about
that.
If
they're
basically
appear
to
be
dead,
we
do
have
a
process
in
this
sdk
governance
stock
that
talks
about
archiving
projects
or
projects
that
become
stale
and
and
shifting
maintainers
to
someone
else.
J
Okay,
I
was
going
to
say
they're,
you
know
it's
best
effort,
it's
all
open
source.
It's
not
like
these
are
products.
This
is
all
you
know
on
people's
own
time
or
managing
their
company
time
on
open
source
pieces.
So
it's
best
effort,
yep
good
point.
B
B
B
B
Oh
yes,
what's
this
cedric,
so
here
I'll,
let
you
let
you
read
the.
B
Okay,
so
there
was
a
little
bit
of
discussion
about
this
and
I
believe
you
don't
have
time
to
read
all
of
it
here,
but
I
believe
most
people
seem
to
be
leaning
towards
saying
that
the
answer
is
to
do
to
use
the
type
field
and
not
the
schema
field.
G
I'm
sorry
go
ahead,
a
lot
of
the
comments
there
are
mine
and
I'm
somewhat
nervous
that
I
may
have
biased
the
conversation
too
much,
but
my
thinking
is
that
the
schema
url
is
something
that
you
consume,
whereas
the
type
is
something
you're
likely
to
use
when
you're
subscribing.
G
So
if
you're
going
to
support
both
v1
and
v2
at
the
same
time,
it
makes
sense
for
that
to
be
in
the
type
so
that
the
consumer
can
choose
which
version
they
get,
whereas
if
you're
just
forcing
everyone
to
keep
up
with
you,
then
maybe
schema
url
makes
more
sense.
Does
that
chime
with
how
other
people
think
about
things?
I.
B
H
I
think
from
semantics
versioning
model.
I
think,
if
you
have
a
breaking
change
in
the
data,
then
then
you
need
to
have
a
way
to
distinguish
that
at
the
subscription
at
the
subscription
level,
if
you,
but
if
you're,
just
evolving
like
if
you,
if
you're
starting
to
add
more
and
more
information
to
the
to
the
payload
without
breaking
the
semantics
of
the
of
of
what
you're
delivering
then
that
sticking,
then
sticking
with
the
existing
version
of
the
of
the
event
type
may
make
sense.
B
G
H
Guys
is
never
guidance,
never
hurts
well,
and
it's
not
normative,
and
so
therefore,
everybody
has
can
have
their
own
their
own
variations
of
it,
but
giving
sending
sending
those
people
into
into
a
direction
who
have
no
concept
of
what
they
should
do
here.
That
that
certainly
makes
sense.
B
G
I
will
I
will
take
an
action
item
to
try
to
do
it,
like
probably
everyone
else
on
the
school.
I
have
many
many
things
on
but
not
least,
I've
got
ecma-c-sharp
stuff,
standardization's
fun.
I
will
see
what
I
can
do
yeah.
Thank
you
very
much.
I
appreciate
that.
B
B
G
Yes,
indeed,
I'm
actually
hoping
to
implement
a
protobuf
event
formatter
in
the
c-sharp
sdk
as
a
separate
package
fairly
soon,
mostly
to
sort
of
prove
that
our
event,
formatter
abstraction,
is
appropriate.
So
I
have
looked
at
the
proto
quite
recently
and
thought
yeah
that
all
makes
sense.
Okay,
cool
does.
G
Yes,
sorry,
I
didn't
intend
to
make
this
meeting
all
about
me.
That's
okay!
It's
all
good!
So
I've
been
busily
at
work
on
a
new
major
version
of
the
c-sharp
sdk
and
so
kind
of
revisiting
quite
a
lot
of
the
decisions
and
implementation
bits
and
parts
of
that
is
http
headers,
and
so
I've
been
looking
at
the
spec
and
trying
to
work
out.
If
I'm
going
to
be
absolutely
rigorous,
I
want
to
be
spot
on
with
the
spec
and
I
found
I
I
couldn't
understand
it
clearly
enough
to
know
what
to
expect.
So.
G
I
guess
the
simplest
question
is
about
halfway
down
that
comment.
If
you've
got
an
attribute
value
of
that
xyz
colon
abc,
what
would
that
look
like
in
an
http
http
header?
Should
the
colons
and
slashes
be
escaped
or
not,
you
know
if
they
were
being
deemed
as
uris,
then
maybe
the
first
colon
wouldn't
be
in
other
ones
might
be,
I'm
not
entirely
sure.
Basically,
we
have
a
mismatch,
because
the
uri
rfc
3986
talks
about
this
bit
of
the
uri
needs
encoding.
This
bit.
G
Doesn't
we
don't
have
uris,
not
always
at
least
so.
We
need
to
work
out,
I
I
would
love
it
if
we
could
work
out
something
that
would
be
backwardly
compatible
and
that's
going
to
be
hard,
but
also
really
really
clear.
With
google
conformance
tests
saying,
if
you
have
an
attribute
value
of
x,
it
should
end
up
in
an
encoded
form
of
y
and
I'm
okay
for
that
to
sort
of
then
leave
rfc
7230,
which
I
also
find
hard
to
understand.
G
But
that's
that's
rfc's
problem,
not
not
ours,
so
that
everyone
can
hopefully
do
the
same
thing.
Encode
the
same
way,
decode
the
same
way.
B
H
G
Would
that
be
in?
Is
that?
What
is
that?
What
is
that
typed?
Well
so
this
would
be.
Presumably
a
string
attribute
the
if
you
doug,
if
you
follow
the
http
yeah,
follow
that
link
and
it'll
be
a
bit
clearer,
because
it
says
the
http
value
is
constructed
from
the
respective
attribute
types
canonical
string
representation.
G
G
But
there
is
a
uri
treatment,
particularly
in
terms
of
encoding
it
as
a
header.
If
we
have,
if
we
can
find
some
something
that
says,
I
will
take
arbitrary
string
that
isn't
a
control
doesn't
have
control,
characters,
bad
surrogate
pairs,
etc
and
encode
this
appropriately
as
a
header
in
a
way,
that's
reversible
and
ideally
doesn't
make
uris
look
completely
weird.
It
doesn't
start
encoding,
slashes
and
colons.
G
Then
we
don't
need
to
give
special.
Well
if
you're
encoding,
an
http
header
and
the
original
attribute
was
a
string,
then
you
do
x.
If
it
used
to
be
a
uri,
then
you
do
y,
and
you
know
it
would
be
particularly
weird
suppose
you
had
is
subject
to
string.
I
think
it
is.
If
you
had
two
suppose,
someone
decided
to
make
the
source
and
subject
the
same
string.
G
B
E
B
G
Yes,
which
makes
me
as
nervous
as
it
probably
makes
everyone
else
on
the
call
yeah
it
does
because
yeah
I
I
want
to
come
up
with
something
that
is
better
defined
than
you
than
referring
to
that,
but
still
backwardly
compatible
with
what
people
have
been
doing
already.
Ideally,
okay,.
G
I
completely
agree
that
we
need
to
do
encoding
and
I'm
happy
enough
with
percent
encoding
and
thrilled
that
we've,
I'm
not
sure
whether
we
are
specifically
saying
percent
encoding
via
utf-8.
But
let's
assume
that
we
are
doing
that.
G
G
What
do
I
encode
reading
rfc
20
7230
section
3
was
not
obvious
to
me
what
the
code
that
I
should
write
should
look
like
and
trying
to
use
various
built-in
library
functions,
such
as
url
encoding.
G
If
I
said
encode
the
data,
it
did
one
wrong
thing.
If
I
said
encode
the
whole
thing
it
did
something
else
wrong
and
fundamentally
because
what
we're
looking
at
isn't
necessarily
a
uri.
H
Yeah,
I
I
yeah
so
your
eyes
are
a
special
art,
this
special
case,
where
we
care
about
the
uri
still
being
a
uri
when
you
have
it
in
the
http
header
or
arguably
jennifer
you
made
it
jennifer
made
a
comment
on
on
in
the
chat.
You
should
feel
always
feel
entitled
to
speak
up.
F
H
I
think
that
is
is
better
than
creating
completely
new
rules.
Certainly-
and
maybe
it
is
that
we're
saying
here's
the
we
do
proceeding
coding,
but
we're
not
doing
that
for
the
year
for
the
ui
character
set.
G
Maybe
that
so
we
we
know
that
we
do
need
to
encode
percent,
because
otherwise
we
yeah
now,
if
we,
if
we
decided
the
only
things
we
need
to
encode
our
percent
and
anything
non-ascii
that
that
would
be
a
perfectly
good
starting
point.
I
wonder
whether
how
that
fits
in
with
existing
implementations,
if,
if
things
are
expecting
other
characters
to
be
encoded-
and
this
was
where
my
ignorance
meant-
that
I
wasn't
proposing
anything
specific
so
that
doesn't
sound
like
it.
So
what.
H
So
I'm
wondering
whether
anybody
has
somewhere
already
invented
that
before
and
it
might
be
interesting,
interesting
to
go
and
hunt
around
in
the
in
the
relevance
related
rfcs
or
whether
there
is
a
well
there's.
A
coding
like
that.
B
Well,
regardless
of
that,
I'm
I'm
more
interested
in
john's
other
comment
about
current
implementations
and
whether
if
we
change
something
it's
going
to
break
something.
So
let
me
ask
some
of
the
sdk
folks
on
the
call
did
any
of
you
guys
even
notice
this
paragraph,
who
does
any
encoding
at
all
or
was
john
just
being
incredibly
anal.
G
It's
it
was
when
I
was
fixing
things
and
trying
to
get
them
working,
but
that
it
came.
We
do
have
tests
for
non-ascii
characters
in
attributes,
and
it
was
when
I
started
encoding
everything
with
some
url
encoding,
at
which
point
those
tests
still
passed,
but
the
test
that
expected
uris
to
stay
unchanged
failed.
B
So,
okay,
wait.
I
want
to
focus
on
slinky
and
scott's
comment
in
the
chat
because
they're
saying
that
things
like
the
go
library
automatically
handles
this,
can
you
guys
elaborate
on
what
you
mean
by
it
just
works
or
or
it
handles
it?
Does
that
mean
it
does
encoding
or
it
just
doesn't
seem
to
be
bothered
by
non-ascii
characters.
C
B
G
Be
just
to
add
a
second
level
of
burden,
because
it's
not
just
that
sort
of
thing,
but
typically,
if
a
header
has
multiple
values,
they
are
comma
separated,
which
means
that
if
you
want
to
have
a
single
value
that
contains
a
comma,
you
need
to
put
double
quotes
around
it
and
and
stuff.
So
that's
where
I
think
a
conformance
test
of
you
know.
This
is
the:
how
does
a
value
of
space
x
space
get
written
on
the
wire,
and
does
it
get
correctly
decoded?
B
It
just
so
you
know
I
just
did
a
quick
test
with
just
for
fun
just
curl,
and
I
gave
it
a
header
with
the
value
of
kama
kama
comma.
It
just
passes
it
through
now.
That
just
could
mean
the
curl
is
just
too
low
level,
and
it's
not
even
going
to
try
to
encode
it's
going
to
give
you
it's
going
to
take
whatever
you
want,
but
at
least
from
a
curl
perspective.
It
doesn't
touch
it.
Yes,.
K
Just
another,
just
another
data
point
I
I
for
for
the
ruby
sdk
we
actually
did
have
to
implement
this
explicitly
and
I
do
remember
going
through
the
process
of
puzzling
out
what
what
this
these
paragraphs
mean,
and
this
and
going
through
several
iterations
of
not
understanding
that
before.
But
I
think
it's,
I
think
it's
quote
unquote
correct
or
at
least
reasonable.
Now,
but
it's
been
a
little
while
since
I've,
I
remember
it
being
confusing.
K
So,
yes,
we,
I
I
believe,
I'm
I'm
looking
at
my
code
right
now.
I
believe
it
was
percent
in
printable,
ascii
or
yeah
passing
you
know,
per
pers
passing
through
printable
ascii.
That's
not
percent
and
percent
encoding.
The
rest.
K
Yes,
well
colon:
what's
the
f
code
for
colon.
B
G
Multiple
multiple
values
thing.
K
K
G
I
think
it's
also
entirely
feasible
that
http
libraries
may
may
handle
commas
and
quoted
strings
and
things
for
us,
but
I
don't
think
they
will
handle
the
sentence
encoding
because,
as
far
as
I'm
aware,
that's
not
part
of
http.
B
So
I'm
curious
about
the
next
steps
here.
It
sounds
like
we
have
at
least
one
sdk
that
actually
did
try
to
follow
these
rules.
I
I
so
I'd
be
curious
to
know
what
the
other
ones
do.
However,
I
I
think
it
also
may
be
worthwhile
to
get
a
proposal
for
what
this,
I
guess,
is
what
jennifer
said
is
you
know,
forking
and
and
clarifying
my
proposal
would
look
like
right.
G
Sort
of
long
lines,
I
think
the
general
idea
of
encode
percentage
anything
non-ascii,
then
reluctant
as
I
am
to
take
on
a
second
action
item.
I
can
work
with
daniel
and
we
can
check
the
check
whether
we're
in
line
and
our
understanding
of
the
rfc
and
c
yeah.
It
may
be
that
actually
an
explanatory
paragraph
explaining
how
to
read
rfc
7230
in
this
case-
maybe
that's
all
that's
required.
G
B
G
Me
to
go
away
talk
with
daniel
danielle
and
I
colleagues
by
the
way
hi
daniel.
So
hence
why
I'm
very
happy
to
to
get
together
with
him
and
talk
this
through.
So
scott.
H
G
Unless
it
is
performing
some
kind
of
encoding
that
in
maybe
in
some
bit
of
rfc
that
I'm
not
aware
of
or
is
sort
of
doing
an
encoding
and
assuming
that
things
will
do
the
same
thing
yeah
I
mean
there's
a
it's.
It's
seven,
but
ascii.
H
That's
what
that's
what's
allowed
in
the
headers
and
and
the
the
fact
that
we
are
putting
8-bit
ascii
into
into
those
headers
practically
is
is,
is
still
not
making
it.
J
Valid
actually
I
I
am
mistaken.
I
was
making
sure
that
our
utf-8
encoding
for
the
the
character
set
for
data
encoding
for
the
payload
worked
out.
H
That's
that's!
That's
the
tragic
with
these.
With
these
with
that
rule,
I'm
pretty
sure
that
these
days
you
can
literally
go
and
send
http
headers
that
have
emojis
and
it
will
work
on
most
stacks
because
because
people
just
don't
think
about
the
constraints,
it
works,
at
least
in
some
in
some
of
those
stacks.
H
So
so
maybe
that
seven
bit
ascii
rule
is
something
that
is,
you
know,
just
loosely
enforced
and
that's
why
some
of
that
stuff
just
works
like.
I
think
I
think,
if
you
just
use
umlauts
so
anything
from
the
the
upper
the
upper
section
of
of
ascii,
then
or
at
the
nc
strings
that
that
will
largely
just
work.
But
it's
still.
G
Illegal,
but
no
it's
it.
I
believe,
having
recently
been
reading
this,
I
believe,
that's
valid,
but
strongly
discouraged
these
days,
there's
an
obs
characters
or
something
rfc
3986
that
says
yeah
you
can,
if
you
really
want,
but
please
don't.
I
Good
okay,
good
data
point
for
the
node
for
the
node:
we
we
don't
do
any
real
parsing
at
all.
We
do
we
do
we'll
throw
if
it's
not
a
string
or
something
that
can
be
converted
to
json.
We
throw
an
exception.
B
Okay,
good
to
know,
thank
you
all
right,
any
other
comments,
all
right
and
john
never
apologize
for
doing
work.
It's
all
good,
all
right!
Okay,
this
one,
I
thought
was
interesting.
B
B
Okay
and
obviously
jem's
question
is
broader
than
that,
but
I
think
the
question
I
have
for
the
group
here
is:
do
we
want
to
go
beyond
saying
what
happens
when
something
vanishes,
but
I'm
gonna,
which
I
actually
propose,
that
we
interpret
a
vanish
from
a
get
meaning
it's
been
deleted,
so
there
is
no
notion
of
deprecation
or
anything
like
that.
B
Or
do
we
want
to
go
as
far
as
what
gem
is
proposing,
which
is
actually
have
real
life
cycle
type
values
associated
with
things,
so
is
it
boolean
or
multi-steps
in
terms
of
removing
stuff?
I
guess
is
the
question,
and
I
want
to
open
that
up
for
discussion.
B
B
B
L
Actually
I
agreed
too,
I
I
think
it's
there
will
be
a
lot
of
variations,
what
this
very
abstract
concept
of
service
maps
to
in
the
specific
environments,
and
so
this
life
cycle
will
also
most
likely
be
handled
differently
in
those
environments
that
would
make
it
really
hard
to
handle
it
here.
F
B
Your
first
question
is
interesting
to
me
because
I
think
that
might
fall
to
the
same
category
as
well.
What
happens
if
someone
fat
fingered,
you
know
a
url
or
one
of
the
other
values
and
maybe
an
hour
later.
They
realized
it
until
they
changed
it
back
it
to
me,
it's
the
same
kind
of
thing
there.
It's
just
you
send
bad
data,
you
know
and
I'm
not
sure
we
necessarily
need
to
go
out
of
a
way
to
protect
to
babysit
people.
B
F
F
Well,
it's
not
supposed
to
do
that,
and
so
then
I
try
to
think
of
like
well
it's
less
about
protecting
us
from
making
mistakes,
but
more
like
being
explicit
about
how
things
should
work
in
the
case
of
uncertainty,
and
so
I
mean
I
mean,
maybe
it
doesn't
matter
so
maybe
I
don't
know
like
I,
I
just
I
think
of
it
from
a
qa
perspective
as
well
from
like
just
like
weird
happening,
and
it's
just
explicit.
B
B
G
A
little
bit
like
do
you
just
delete
a
page
from
the
internet,
or
do
you
put
a
redirect
in
place
to
say?
Oh
well,
I
know
where
you
meant
to
go,
I'm
going
to
be
helpful.
We
don't
necessarily
need
to
require
stuff
in
order
to
say
it
would
be
a
nice
idea
and
to
provide
some
part
of
the
protocol
to
be
able
to
say.
Please
don't
come
here
again
or
it's
gone
over
there
or
whatever.
B
Up,
okay,
so
jennifer,
it's
interesting.
I
I
I
I'm
just
obviously
just
just
my
two
cents,
but
I'm
I'm
less
inclined
to
force
a
deprecated
state
or
to
enforce
a
state
system,
but
I
I
can
be
sold
on
the
idea
of
including
an
optional
attribute
that
has
something
semantics
along
the
lines
of
by
the
way
this
is
going
to
be
removed
at
this
date,
and
people
can
optionally
set
it
if
they
want
to
give
a
warning
to
people.
But
that's
that's
not
quite
the
same
thing
as
an
entire
life
cycle.
To
me.
F
I
I
I
like,
I
have
been
convinced
now,
having
heard
john's
sort
of
way
of
thinking
of
it
of
like
oh
yeah,
like
we
could
make
it
an
optional
thing,
and
then
it's
more
of
something
that
you
could.
We
could
have
a
recommended
practice
and
then
it
makes
it
more
like
people
can
be
more
explicit
or
not.
So
I
feel
like
that's
where
I'm
at
right
now
and
in
terms
of
thinking
about
it.
B
F
Like
an
optional
state
like,
if
you
have
the
ability
to
have
this
optional
state,
where
you
can
add
sort
of
the
context
that
then
people
you
can
for
your
own
service,
that
you're
defining
you
are
able
to
set
that
and
be
explicit
about
it,
and
if
we
have
some
way
like
I
I
keep
thinking
of
like
here's,
the
spec
and
then
here's
the
implementation
and
like
or
sample
implementation
and
recommendation
that
that
feels
like
it's
a
space
where
people
can
leverage
different
styles,
just
like
not
ever
some
people
just
delete
pages
instead
of
providing
redirects.
F
That's
why
I
really
like
john's
way
of
speaking
about
it.
Oh
I'm
so
sorry,
john.
B
He
was
shocked
that
you
actually
listened
to
him.
Okay,
anybody
else
want
to
chime
in.
M
Yeah,
so
I
guess,
with
all
worries
about
sucking
up
to
doug,
I
actually
like
where
you
were
headed
with
your
comment:
doug,
the
the
fact
that
it's,
you
can
add
extra
information
into
some
kind
of
attribute
to
give
people
a
heads
up
that
they
can
look
at
because
the
the
the
problem
with
making
this
too
explicit
is
the
the
the
failure
modes
around
things
vanishing,
whether
it's
a
you
know,
transient
fluttering
of
the
service
coming
up
and
down
for
whatever
reasons
like
the
fat
finger,
examples
or
whatever
they
like.
M
All
of
those
are
still
going
to
happen,
even
if
you
somehow
mandate
an
explicit
life
cycle
right,
so
the
the
code
pass
for
people
who
actually
care
about
the
higher
quality
of
service
implementations,
giving
them
a
heads
up
and
managing
you
know,
deprecation
periods
and
all
those
cool
things
like
and
trying
to
make
that
completely
discoverable
automatically,
rather
than
out
of
band
human
things.
M
F
It
is
the
is
the
culture
of
not
responding
verbally
is
that
is
that,
okay,
to
be
like,
oh
that's
interesting,
is
that
that's.
B
F
B
F
I
appreciate
it
there's
a
lot
to
think
about
here.
M
Thank
you.
I
I
mean
I
I
I
I
tell
you
my
personal
bias
when
I
design
protocols
like
this
is
like
I,
I
it's
all
about
failure
modes
to
me
and
life
cycles
like
so
all
of
my
systems
are
basically
you
know
some
form
of
finite
state
machines
and
those
kinds
of
things.
So
I
totally,
I
totally
agree
with
the
the
the
intent
that
you're
talking
about
it's
just
in
practice.
M
If,
if
the,
if
the
hardest
failure
modes
are
the
ones
where
it's
it's
fluttering
and
transient
like,
I
can
give
all
sorts
of
great
examples
at
you
know:
lower
network
levels
where
we're
literally
people
take
weeks
to
try
and
discover
some
of
these
problems
because
they
didn't
make
their
system
resilient
enough.
So
I
agree
I
it
just
doesn't.
B
Okay,
so
tell
you
what
let
me
do
this:
that's
I'm
not
sensing
a
a
broad
consensus
yet
and,
as
jennifer
said
that
she
wants
to
think
about
it.
I
think
other
people
need
to
think
about
it
as
well.
So
there's
no
decision
on
here
we'll
save
this
again
for
next
week,
and
maybe
we
people
will
do
some
more
thinking
about
it,
but
we
did
have
some
interesting
options
mentioned,
so,
let's
just
hold
off
on
on
making
a
decision
on
either
this
one
or
the
next
one,
because
I
think
they're
both
very
much
related.
B
So
let's
hold
off
on
that,
but
think
about
during
the
week
and
jennifer
I
I
just
so
you
know
I
just
get
so
excited
when
people
speak
up
because
a
lot
of
times
people
in
the
group
get
very
quiet
on
these
calls.
So
I
just
get
excited
that
somebody
chooses
to
speak
up,
so
you
did
and
I
jumped
on
it.
So
I
mean
I
encourage
it.
So
I
didn't
mind
to
pick
on
you.
F
No,
no,
no,
I
did
not.
I
did
not
perceive
it
as
picking
at
all.
I
was
just
like.
I
was
like
oh
okay,
I'm
thinking,
but
I
do
want
to
say,
like
I'm
relatively
new
to
this
particular
community
of
folks,
I
didn't
realize
it
existed
until
recently
and
I
just
want
to
say
it
like
it's
so
fabulous.
I
love
I've
been
here.
I
guess
like
three
weeks
or
something
and
like
the
the
style
of
how
you
y'all
run
the
meeting
and
it's
so
collaborative.
I
really
think
it's
great.
B
Got
some
good
folks
here,
so
it's
all
been
good
all
right.
In
that
case
anything
else.
On
these
two
topics,
as
I
said,
thank
you
scott.
I
I
even
if
we
come
up
with
a
different
system,
scott,
I'm
going
to
keep
doing
roll
call
just
to
annoy
the
crap
out
of
you,
okay,
so
anything
else
on
these
two
topics.
B
If
we
move
forward
okay,
oh
slinky,
since
you're
on
the
call
now
was
there
anything
you
wanted
to
mention
about
the
sql
query
expression
since
you
weren't
here,
we
didn't
really
talk
much
about
it
other
than
to
say
that
I
noticed
there
was
some
activity
today
going
on,
so
I
thought
it
might
be
premature
to
try
to
merge
it,
but
that
I'm
hoping
by
next
week
we
might
be
able
to
merge
it
because
the
amount
of
traffic
will
slow
down
and
that
it's
a
it's
probably
good
enough
as
a
first
rough
draft
to
go
in,
but
I
want
to
give
you
an
opportunity
to
speak
to
it.
C
J
B
Okay,
hold
on
a
minute
I
might
realize
I
jumped
the
gun
on
these
notes.
Okay,
cool!
All
right!
Are
there
any
other
of
these
pr's
that
we
need
to
talk
about
slinky?
You
may
have
been
doing
some
changes,
or
maybe
I'm
sorry,
those
clemens.
I
think
clemens
made
some
changes
recently
today.
Obviously
it's
too
certain
to
merge,
but
please
people
take
a
look
at
that
when
you
get
a
chance,
because
I
think
they're
going
to
make
some
changes
recently,
all
right
any
other
topics.
People
want
to
bring
up.