►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211108
A
All
right
it
is
november
eight,
it
is
at
least
in
california,
it's
the
first
day
after
daylight.
Savings
time
switched
so
first
weekday
anyways.
Hopefully
that
didn't
screw
up
too
many
people,
but
yeah
happy
happy
november
8th
keep
on
moving
along
here.
There's
a
few
gaps
up
for
discussion
today.
I
think.
That's
all
that's
on
the
on
the
roadmap.
A
I
want
to
thank
shane
because
I
asked
him
if
there's
any
chance,
he
could
get
something
together
this
week
and
he
did,
which
is
awesome
for
the
l4
matching
gap
that
he's
been
working
on.
We
have
a
couple
that
are
going
to
going
to
come
up
next
week,
so
anything
that
we
could
get
in
earlier
was
great.
So
I
think
we've
got
a
draft
from
him
that
we
can
go
over
today
and
then
there's
just
some
follow-up
on
some
existing
gaps.
A
That
are,
I
think,
in
their
final
phases,
but
we'll
see
so
without
further
ado,
let's
get
into
and
as
always
feel
free
to
add
to
this
agenda
at
any
point
but
yeah
with
that,
let's
get
into
the
path
rewrite
and
redirect
gap.
There
have
been
a
few
changes
over
the
past
week
and
I
would
say
the
main
one
here
is
that
there
were
two
two
supported
path:
replacement
types.
A
One
was
absolute
where
you
would
just
replaced
the
entire
path
with
the
given
value
and
the
other
was
prefix,
but,
as
has
got
some
feedback
and
comments
as
much
as
prefix
is
fairly
broadly
supported.
If
we
ever
wanted
to
extend
it,
it
would
get
quite
messy.
You
can
imagine
that
if
you
have
a
path
that
specifies
a
prefix
match
and
an
exact
match,
but
you
only
replace
the
prefix
match,
then
that
it
gets
messier
than
I
would
like.
A
A
That,
unfortunately,
is
going
to
be
a
little
bit
harder
to
define
conformance
wise,
I
think
extended
is
about
as
good
as
we
can
do
here,
but
it
does
give
us
a
lot
more
flexibility
going
forward.
So
I'd
say
that's
one
of
the
biggest
changes.
That's
happened
in
the
past
week
on
this
gap,
and
then
the
other
thing
that
I
wanted
to
highlight
is
well
related
to
that
field.
Type
level
conformance
right
and
I
think
harry
you've
had
some
comments
about
how
messy
conformance
could
potentially
get
here.
A
I
think
I
think
it's
entirely
possible
to
define
it,
but
it
does.
It
does
mean
that
instead
of
implementations
either
support
this
feature
or
they
don't.
They
support
portions
of
this
feature,
I
think
that's
a
reasonable
way
to
go,
but
I
just
wanted
to
highlight
that
downside
of
this
approach-
I've
talked
I've
talked
a
bunch
about
these
two
things.
Does
anyone
want
to
jump
in
the?
Do
you
have
thoughts
on?
A
Yeah,
I
think
you're
right
there.
I
think
this
is
not
completely
new
territory
and
I
feel
like
it
is
unfortunately
inevitable,
with
the
kind
of
api
we're
trying
to
build
here.
I
I
can't
think
of
another
alternative,
but
other
than
just
well.
If
not
everyone
supports
it,
we
just
won't
do
it,
which
is
really
kind
of
what
we're
trying
to
avoid
with
this
api,
and
so
I
think,
since
we
are
trying
to
provide
this
kind
of
consistent
way
to
express
more
advanced
functionality,
this
is
probably
the
way
to
go.
D
I
I
do
I
do
see
like
you
know
there
is
like
like
I
do.
I
do
see
how
it
is
related
to
ingress,
and
you
know-
and
there
is
some
prior
art
ingress,
but
I
I
don't
think
that's
a
completely
fair
comparison,
because
ingress
is
like
a
fairly
straightforward
api.
You
know
there's
this
little
one.
One
thing
that
we
have
in
there
is
like
path,
type
path,
match
type.
D
D
So
we
are
not
increasing
the
problem,
but
we
have
to
be
careful
when
we
introduce
these
things,
because,
as
a
user,
you
know
the
user
will
be
like
okay,
I
need
to
redirect-
and
you
know
they'll
be
just
configuring
that
you
know
they
won't
go
and
read
our
documentation
or
do
any
like
you
know,
things
will
just
stop
working
for
them
and
it's
very
hard
for
them
to
to
get
any
feedback
on
these
things
is
my
concern.
So
go
ahead.
James.
E
Yeah,
I
was
actually
going
to
say
something
sort
of
complementary
to
that.
There's
always
going
to
be
cases,
I
think,
as
we
try
to
get
more
complex,
where
controllers
aren't
going
to
support.
You
know
some
field
like
even
even
regex's
right,
you
know.
There's
there
was
a
long
thing
in
ingress
about
well.
What
flavor
of
rejects
is.
Do
we
have
to
do
implementations
have
to
support,
so
maybe
we
need
to
think
about
like
a
standardized
way
for
controls
to
say
I
didn't
support
this
thing.
B
Yeah,
I
was
about
to
say
it
sounds
like
a
condition
to
me.
I
think
the
I
think
there's
two
parts
to
this.
That
is
the
that
we
need
that
we
do
need
to
consider
at
some
point.
I
mean
I
spent
some
time
thinking
about
this
already,
but
like
that,
that's
how
do
you
specify
the
performance
bits
so
and
which
is
sort
of
two?
Some
things
are
that,
which
is
how
do
you?
E
B
Yeah,
I
think
that
that's
got
to
be
machine
consumable,
because
at
the
end
of
the
day,
it's
going
to
be
complicated
enough
that
it's
not
going
to
be
easily
human
possible.
But
if
it's
machine
consumable,
then
you
can
have
a
you
can
have
tools
that
will
test.
If
you're
you
know,
if
you
want
to
move
between
implementations,
you
can
be
like
here's,
the
source
gateway,
here's
target
gateway,
what
one's
going
to
work?
B
And
you
should
be
reasonably
straightforward
to
to
to
do
that
sort
of
test
you
so
that
you'll
know
ahead
of
time
you
as
well
or
or
even
if
it
is
machine
consumable
as
well.
There's
other
things
you
can
do,
and
the
other
option
is,
of
course,
that
you
can
just
have
to
have
a
route
point
two
gateways
and
then
because
the
status
is
named
space
by
the
by
the
owning
by
the
implementation
that
is
pointing
to
that
gateway.
Then
you
can
have
the
conditions
on
there.
That
say:
hey!
B
A
Yeah,
I
I
agree
with
that,
and
I
I
think,
because
we
already
have
that
capability
in
routes
like
like
you're,
pointing
out
the
I
think
route
gateway
status
is
what
we
call
it.
Something
like
that,
adding
a
condition
at
that
point
is
going
to
be
relatively
straightforward,
so
yeah
that
seems
like
a
very
good
takeaway
and
something
that
applies
more
broadly
than
just
this
one
gap,
but
something
that
we
we
definitely
need
to
create
a
follow-up
for
so
james.
A
D
A
D
So,
like
one
use
case
that
comes
to
mind,
is
you
know
regular
expression
substitutions?
So
this
is
like
your
fu
bar
and
then
you
have
a
rejects
capture
group
and
you
know
you
do
substitution
based
on
you
know,
like
dollar,
one
slash,
foo,
okay,
yeah.
There
are
like
these
things
that
I
have
seen.
I
don't
know
how
common
they
are,
but
I
have
observed
them.
D
D
A
A
D
Yeah
I
mean
practically,
even
though
we
have
regular
expressions
like
defined
as,
like,
you
know,
a
match
type.
It
is
not
portable
across
implementations,
so
the
user
still
has
to
you
know
see:
okay
is
the
regex
engine
same
okay?
Is
this
rejects
doing
the
same
thing
in
another
implementation,
so
from.
D
G
Or
go
ahead,
oh
just
wonder
if
there's
maybe
a
way
for
something
like
regex,
it
feels
fairly
straightforward
because
it's
kind
of
like
there
are
a
few
options
to
pick
from
something
like
a
enum-ish
annotation
on
that
field,
rather
than
just
like
a
bullion
like
supported
or
not
to
like
add
a
qualification
of
its
pcre,
regex
or
whatever
other
kind
of
rejects
the
specific
implementation
supports,
but
like
maybe
for
less
well-defined
stuff.
Like
a
vendor
note
kind
of
thing,
I
don't
know
how
practical
that
is.
B
Yeah,
I
think
that
the
point
that
harry
made
is
pretty
fair,
like,
if
you
think
of
it
in
terms
of
performance.
How
would
you
def,
if
and
we
do
have
a
regex
match
or
a
regex
replace?
That
is,
you
know
that
has
extended
conformance.
That
means
part
of
what
extended
conformance
means
is
that
we
have
upstream
available
at
the
end
of
the
day.
B
Is
that,
ideally,
we
should
have
upstream
available
tests
for
that
extended
functionality
that
mandate
that
everybody
who
supports
that
extended
functionality
does
it
in
the
same
way
you
because
of
what
harry
said
and
what
you
and
what
mike
was
referring
to
like
it's
not
really
possible
to
do
that.
Unless
you
have
something
that
says
this
is
the
flavor
of
rejects
that
that
we're
talking
about
so,
and
I
don't
I
feel
like
you,
I
think
your
your
points
are
fair
mike,
but
the
I
feel
like
having
something
where
it's
like
that.
A
G
A
And
I
think
I
think
that
lines
up
pretty
nicely
with
what
nick
has
been
describing
of
a
way
for
gateway
classes
to
programmatically
describe
what
they
support.
That's
something
that
that
has
been
kind
of
a
long-term
disc,
ongoing
discussion
here
and
the
flavor
of
regex
is
likely
going
to
be
true
for
the
entire
implementation.
Not
just
you
know,
a
specific
protocol
or
route
or
whatever,
and
and
so
in
that.
In
that
sense,
it
probably
does
make
sense
to
bubble
that
all
the
way
up
and
include
that
in
that
discussion.
B
Yeah,
I
think
so
that
yeah,
so
yes,
I
think
so
it
does,
it
would
make
sense
to
be
able
to
say
yeah
hey
if
there's
any
references
to
regex
this
implementation
does
pcr
or
whatever
you
know,
and
then
the
good
part,
then,
is
that
you
can
say
you.
The
following:
regex
types
are
extended
support
and
have
tests
for
them.
B
Any
other
ones
are
implementation,
specific
sport
and
don't
have
tests.
You
know
the
that
that,
in
my
mind,
is
one
of
the
biggest
benefits
of
performance
testing.
Yeah.
Is
that
if
you
could
do
something
like
that
and
describe
things
in
that
way,
the
you,
then
you
can
always
be
confident.
You
have
a
test
that
tests
things
that
have
extended
and
that's,
I
think
what
we
should
be
aiming
for
everything.
That's
core
has
mandatory
tests.
Everything
extended
has
optional
tests,
but
we
do
to
provide
tests
everything,
that's
implementation,
specific.
A
Yeah
that
makes
a
lot
of
sense
and
and
I'd
say,
also.
Another
benefit
of
this
kind
of
approach
is,
if
you're,
really
just
looking
at
a
cluster
at
the
gateway
classes
in
your
cluster,
you
can
kind
of
surmise
gateway
classes
that
might
be
portable.
You
know,
like
these
five
gateway
classes,
all
support
the
same
flavor
of
regex
and
the
same
subset
of
features
that
I'm
using.
A
So
I
should
be
able
to
go
between
them
pretty
easily,
whereas
this
one
doesn't
support
this,
that
I
really
care
about
or
whatever
or
I
need
to
translate
to
a
different
kind
of
regex.
When
I
move
to
you
know,
none
of
this
is
ideal,
but
I
think
it
makes
it
a
little
bit
easier
to
process
if
you
have
that
all
described
in
a
central
place.
B
Yeah
yeah,
I
think
I
think,
there's
a
bunch
of
stuff
there
that
we
can
talk
about
like
there's
some
discussion
in
the
chat
about
you
know
what
generates
the
the
you
know.
I
don't
support
that
thing,
but
I
think
there's
there's
a
bunch
of
stuff
that
we
can
talk
about
about
where
that
information
comes
from
and
how
it
gets
set
up
and
all
that
stuff.
But
I
think
that
that
feels
like
something
that
will
go
in
the
actual
conformance
design
gap
yeah,
the
one
that
I
did
earlier
was.
B
D
A
Yeah
thanks
for
bringing
it
back
on
track,
while
on
to
this
original
question
and-
and
I
had
thought-
I
probably
misunderstood-
and
I'll
open
it
up,
but
my
my
understanding
was
that
this
was
a
supported
change
or
a
reasonable
change.
But
if
anyone,
if
anyone
has
hesitation
about
this
change,
this
be
a
great
time
to
bring
that
up.
I
may
have
misunderstood
discussion
here.
D
A
D
A
A
That
would
be
nice,
but
unfortunately,
the
the
underlying
implementations
of
you
know,
whatever
whatever
vendor
will
only
you
know,
support
a
given
flavor
of
regex
in
most
cases.
So
if
you
know
like
many
of
these
controllers,
you're
just
programming
another
data
plane,
then
you
don't
really
have
that
choice.
To
make
often.
D
A
A
The
the
thing
that's
the
thing
this
enables
at
least
theoretically,
is
that
it
enables
you
to
write
this
one
filter
and
have
it
applied
to
two
separate
matches.
At
the
same
time,
say
a
exact
match
and
a
prefix
match,
which
was
currently
not
possible.
With
the
very
specific,
I
will
only
replace
path,
prefix
matches
kind
of
thing.
B
It
feels
like
the
downside
of
having
to
do
two
things
at
once.
Is
that
that
then,
then
so,
and
I
think
the
reason
why
we
veered
into
the
extended
conversation
about
regex
is
that
if
we
keep
it
as
replace
path,
prefix
match
you
have
to
have
like.
If
you
want
to
replace
the
prefix
and
like
an
exact
match,
then
you've
got
to
have
two
filters
like
place.
Part
prefix
match
replace
path,
exact
match,
but
the
plus
side
of
that
is
that
then,
then
we
can
say
a
filter
of
type
replace,
replace
path.
B
B
A
A
A
A
D
B
Right,
like
you
know,
like
the
filter
itself,
is
maybe
core
performance,
but
then
there's
extended
fields
inside
the
filter,
which
is
like
a
microcosm
of
the
same
problem
that
we
have
where
the
http
route
you
know
or
the
gateway
object,
is
core
performance.
But
there
are
fields
inside
it
that
are
extended
performance.
B
So
I
don't
think
there's
much
way
that
we're
ever
going
to
get
around
the
fact
that
that
we
have
like
the
conformance
is
kind
of
fractal,
that
you
know
that
some
objects
within
and
some
objects
are
going
to
be
called
conformance
and
I'm
making
air
quotes.
But
they're
going
to
have
bits
that
are
not
conformant.
A
D
B
B
A
All
right:
well,
I
don't!
I
don't
want
to
monopolize
all
the
time
with
this
pr,
because
there
are
other
conversations
potentially
more
important
than
this
one
on
the
agenda.
So
there's
a
lot
more
to
discuss
here,
I'll
play
around
with
it
some
more
it's
interesting
for
anyone
watching
the
recording.
After
john
saying
this
is
a
remarkably
popular
feature
request
for
istio
so
good
to
have
that
as
background
that
people
do
want
regex
rewrite
support,
at
least
for
some
implementations,
yeah.
B
That
sounds
awful,
yeah,
good
point,
sir.
Yes,
that
is
why
we
don't
do
it
in
contour.
Is
that
the
http
proxy
document
defines
inclusion
into
can
define
inclusion
in
terms
of
path
prefixes?
But
if
you
allow
a
regex
match
in
there,
then
then
deciding
what
gets
included
and
what
kids
doesn't
becomes
like
a
horrifying
nightmare.
D
B
A
A
If
anyone
has
thoughts,
I
hope
I'm
not
quite
sure
how
I
want
to
approach
the
next
change
here,
but
I
hope
to
have
an
update
out
in
the
next
day
or
two
based
on
this
conversation
or
any
feedback
I
get
on
the
pr.
So
if
you
have
thoughts
continue
discussion
here
in
slack
wherever
wherever
is
easiest,
we
can
go
from
there.
A
F
Sure
so
this
is
based
on
issue
735
in
735.
It
was
originally
kind
of
requested
to
do
like
destination
matching.
Although
the
question
of
why
not
do
source
matching
came
up
so
for
the
purposes
of
this
draft
so
far,
I'm
actually
going
with
doing
both,
but
I've
intentionally
and
I've
mentioned
it
in
the
non-goals
dropped
source
ports.
F
I
don't
we
don't
see
a
case
for
it
really
yet
so
I'm
just
leaving
it
out
of
this
because
it's
something
we
can
add
later
once
we
see
cases
and
kind
of
understand
better
what
we
need
it
for
the
long
and
short
of
it.
If
you
scroll
down,
is
adding
two
types
to
the
api,
a
network
match
and
a
traffic
match,
and
what
I'm
suggesting
is,
instead
of
just
for
matching
ports,
it's
more
or
less
just
using
the
existing
port
number,
but
for
matching
addresses.
F
I
had
this
sense
that
it
could
very
easily
become
something
beyond
you
know,
just
a
single
ip
address
that
you
would
actually
want
to
match
on.
So
I
intentionally
wrapped
address
inside
of
network
match
with
the
and
I,
if
you
scroll
down
with
the
kind
of
growth
room
for
things
like,
maybe
you
want
to
add
a
mask
and
say
you
actually
want
to
do
an
entire
subnet
for
this
match,
but
that's
not
actually
what
I'm
suggesting
we
do
as
part
of
this
spec
just
pointing
out
to
kind
of
leave
the
room
open
for
later.
F
F
F
E
Yeah,
it's
going
to
say
one
thing
that
jumps
at
me
with
the
traffic
matching
syntax
is:
we
should
take
a
look
at
kibany's
network
policy
and
maybe
we
can
use.
Maybe
we
can
make
the
the
field
grammar
looks
similar
so
that
we
don't
have
to
express
this
so
that
when
people
are
trying
to
do
this
stuff,
they
can,
you
know,
reuse,
the
idioms
and
language
that
they've
used
in
network
policy
in
gateway
policy
as
well.
F
B
Yeah
I
was
gonna
say
I
like
to
look
at
it
looks
cool
the
I
think,
yeah
leaving
leaving
a
slot
for
to
have
to
have
a
mask
is
a
very
good
idea,
because
and
I'm
pretty
sure
that
that's
how
network
policy
works
so
rob
you
probably
know
better
than
I
do
again
yeah.
I
have
never
seen
anything
where
treating
a
single
ip
address
as
yeah
a
subnet
with
a
with
a
32
network
mask
was
was
not
the
simplest
way
to
do
single
ips.
A
Cool
great
great
feedback
all
around,
and
I
yeah
somehow
I
I
had
missed
suggestion,
but
it's
it's
a
great
one
to
to
try
and
line
this
up
with
network
policy
api,
because
this
this
is
very
similar.
You
know
initially,
when
I
started
talking
about
this,
it
seemed
oh
yeah.
This
is
in
a
different
world,
but
you're
right.
What
what
the
this
proposal
lines
up
very
closely
with
what
the
network
policy
api
covers,
at
least
in
terms
of
what
you
can
configure.
E
F
F
F
H
B
F
A
Yep,
I
agree
with
that
and
I
yeah
I'm
really
curious.
We
need
to
spend
a
bit
of
time
looking
through
implementations,
potential
implementations
of
this
api
and
to
see
if
we
could
get
some
of
these
to
core.
I
feel
like
there's
potential
for
for
some
of
these
to
be
core,
but
at
the
very
least,
like
nick
said,
extended
seems
very
reasonable.
F
A
A
A
A
I
I
think
the
biggest
thing
I
wanted
to
highlight
is
this
ongoing
thread
and
discussion
about
well
this
this
comment.
Actually,
let
me
let
me
just
open
up
the
the
full
thing,
because
basically,
what
we're
saying
and
we've
had
this
discussion,
but
that
any
validation
we
provide,
whether
it's
through
a
web
hook
or
crd
annotations,
is
not
something
that
can
be
truly
relied
on
as
a
security
mechanism,
because
anything
we
do
as
api
authors
can
be
bypassed.
A
You
can
modify
a
crd.
You
can
delete
a
web
hook.
You
can
whatever.
If
you
have
that
level
of
access,
admittedly,
those
are
both
pretty
elevated
levels
of
access,
but
if
they
enable
you
to
further
elevate
your
access
by
you
know.
Basically,
you
know
telling
a
controller
to
do
something
like
it
really
shouldn't
do,
or
you
know,
taking
advantage
of
access
that
a
controller
might
have
that
you
otherwise
wouldn't
have.
A
Hopefully,
some
of
those
can
be
fixed
upstream
eventually,
and
then
I
added
a
another
tracking
issue
and
that's
based
on
this
com
set
of
comments
here
right
that
it
could
be
useful
if
we're
saying
that
all
implementations
really
should
be
doing
some
set
of
validation
locally
on
resources
to
ensure
they're
not
introducing
some
kind
of
security
risk.
They're,
not
you
know
whatever.
A
A
So
I
created
a
tracking
issue
to
work
on
some
kind
of
shared
validation
like
this
yeah.
That's
that's
a
summary
of
this
discussion.
I
wanted
to
highlight
this
because
I
know
not
everyone's
been
involved
in
this
discussion
and
also
wanted
to
give
anyone
an
opportunity
to
give
some
input
if,
if
this
feels
reasonable,
you
know
if,
if,
if
there
are
any
better
alternatives
than
this
kind
of
shared
validation
package,
I,
if
we're
being
too
restrictive
by
saying
that
the
validation,
we're
writing,
can't
really
be
trusted
and
any
any
thoughts
comments.
A
B
Yeah,
I
I
don't
either,
but-
and
I
think
that
it
is,
if
we
are
gonna
say
it
feels
like
if
we
are
going
to
do
this.
The
only
way
to
do
it
safely
and
in
a
fair
way
for
everybody
is
to
say
there
is
an
upstream
validation
package.
Part
of
the
contract
for
any
implementation
is
that
you
must
run
the
validation
on
every
object
when
you
ingest
it
and
reject
the
object
if
it
fails
the
validation
yeah,
and
that
that
means
that,
then
that
then
it's
quite
straightforward
to
include.
B
A
Does
it
does
feel
like
something
that
has
to
be
theoretically
possible
by
importing
the
upstream
packages
that
already
do
this,
but
I'd
have
to
do
some
digging,
but
this?
Actually,
this
actually
goes
into
my
next
question
here,
and
that
is-
and
I
struggled
with
this
and
I'm
not
sure-
I'm
not
sure
how
this
impacts
our
versioning
plan.
A
But
one
of
one
of
the
ideas
in
versioning
is
that
we
want
to
be
able
to
introduce
future
api
versions
that
loosen
validation
in
some
way
and
and
obviously
we
can't
predict
what
that
loosened.
Validation
is
going
to
be
we're
going
to
look
like,
but
there
are
some
things
where
we
maybe
could
what
you
know.
What
what
this
my
perspective
on
this
shared
validation
package
is
to
try
to
restrict
security
risks.
You
know
to
restrict
potential
vulnerabilities
but
yeah
as
a
rough
example.
A
You
know
I
I
we
we
allowed
longer
names
now,
but
because
my
implementation
was
built
with
v0.4.0,
I
it
will
completely
ignore
any
resource
that
has
longer
names
or
drop
it
or
whatever,
because
it's
you
know
it's
built
in
imported
validation,
says
that's
not
valid,
that's
a
bit
of
an
extreme
case,
but
that's
just
one
of
the
things
as
I've
just
been
starting
to
process
what
a
shared
validation
package
could
look
like.
I
I've
had
some
concerns
about
how
it
could
potentially
limit
interoperability
right
between
different
versions.
D
Yeah,
I
think
this
I
brought
a.
I
have
a
similar
comment
on
this
pr
as
well
where
by
you
know,
since
we
are
saying
that
you
know
new
versions
can
loosen
things
or
you
know,
introduce
fields
and
whatever
an
implementation
could
choose
to
only
say
like
okay,
we
support
these.
These
these
bundle
versions
specifically
and
and
if
there
are
other
bundle
versions
installed,
you
know
they
fail
whatever,
like
the
implementation,
has
the
choice
to
do
that
right,
because
I
think
the
way
I
have
been
processing
this.
D
Let's
say
you
know
you
have
a
new
version
x,
plus
one
and
the
version
and
implementation
was
programmed
against
version
x
to
write
code
in
order
to
be
completely
resilient
with
you
know
anything
that
can
change
in
x
plus
one.
It's
not
anything.
You
know
we
are
drawing
down
a
subset
to
definitively
say
that
does
not
introduce
any
security
risk
is,
is
challenging.
You
know,
especially
given
that
the
surface
is
pretty
large,
relatively
large,
so
does
it
make
sense
that
you
know
implementations
like
say
that?
D
G
I
mean
that
makes
sense
to
me
and
kind
of
like
the
case
where
I
think
of
where
there,
like
could
be
like
an
actual
risk,
is
something
like
the
difference
between
like
allowing
a
string
to
include
a
regex
match
where
that's
something
that
you
don't
necessarily
want
to
like
just
allow.
If
the
spec
gets
looser
without
the
implementation
explicitly
opting
into
it.
A
Yeah
that
that's
a
good
point
we
we
do
have
to
be
careful
here.
I
I
was
hoping
that
we
had
sufficient
guardrails
that
we
wouldn't
have
to
be
quite
that
restrictive,
but
you
know
the
the
safest,
the
safest
thing
for
any
implementation
to
do
is
always
going
to
be
to
just
support
what
they
know
and
nothing
more.
I
that
is
unfortunate,
though,
because
you
know
it
limits.
A
A
D
But
yeah
yeah
the
reason
for
that.
Like
my
apprehension
to
like
not
like
not
making
like
you
know,
having
explicit
version
compatibility
is,
let's
say
you
lose
on.
Any
validation
like
mike
gave
a
good
example.
It
probably
wouldn't
highlight
a
bug,
you
know
on
the
surface,
but
it
could
it
could
open
up.
You
know
it
might
be
configuring
the
implement
like
and
like.
Let's
say
you
lose
on
it
to
reject
smart
and
you
know
it
everything's
still
working
fine,
but
it
is,
you
know,
opening
up
a
security
hole.
D
G
And
some
of
the
like
tooling
proposals
here,
I
think,
can
really
ease
that
burden
for
implementations
too,
like
if
there
is
a
shared
suite
that
you
can
easily
upgrade
to
the
next
version
of
for
compatibility.
If
tests
for
this
are
included
in
the
conformance
suite
and
you
can
opt
into
a
newer
version
of
that
or
a
subset
that
includes
like
a
new
set
or
something
like
that.
That
could
make
it
much
easier
to
ensure
and
like
quickly
move
to
stay
compatible.
B
Yeah,
I
think
that's
definitely
what
I
in
my
mind,
what
we're
aiming
for
with
the
conformance
test
is
that
they
are
part
of
their
version,
part
of
the
bundle
and
when
you
bump
the
bundle
version,
you
get
the
new
version
of
the
performance
tests
and
that
way
you
if
you
bump
the
version
and
everything
you
and
everything
works
code
wise
then,
and
you
run
the
tests
and
all
of
a
sudden,
you
do
some
loosening
catches.
You
then
test
catch.
B
It
then
you're
great,
I
think,
harry's
right
to
say
well,
there
may
be
subtle
bugs
about
loosening
validation.
I
think
we
need
to
be
really
careful
about
loosening
validation,
but
I
don't
think
that
there's
any
way
to
programmatically
get
a
programmatically
get
around
that
like
we
are
always
going
to
have
to
be
really
careful
about
this
new
validation.