►
From YouTube: QUIC WG Interim Meeting, 2021-04-21
Description
QUIC WG Interim Meeting, 2021-04-21
D
C
E
D
F
G
H
So
I
think
I
might
have
fixed
it.
The
webex
app
was
not
happy
about
logging
me
in
as
the
working
group,
but
it
appears
to
have
done
so.
H
A
Oh,
I
was
looking
on
the
wrong
side.
Apologies
for
that
then,
okay!
So
thank
you.
Everyone
for
your
patience,
I'll
look
into
the
camera
that
you
can
see
into
my
eyes.
This
is
the
work,
quick
working
group
interim
meeting
on
the
special
topic
of
version
negotiation.
A
So
thank
you
to
all
those
have
joined.
As
mentioned,
we
have
a
note
taker
chris
wood.
I
can't
see
his
name
in
there,
but
I
presume
he's
one
of
the
working
group
or
researchers
eric
yes
thanks,
but
if
anyone
would
like
to
help
him,
that
would
be
fantastic.
A
Similarly,
if
we
got
a
volunteer
for
job
describing,
I
can't
imagine
that's
too
much
work.
Would
anyone
like
to
take
that
mantle.
A
Okay,
I
I
can
probably
do
it
and
I'll
get
on
once
since
we've
handled
some
of
the
the
chair
administrative
year.
So
let's
cover
the
note.
Well,
let's
just
touch
on
the
agenda.
First,
no
we'll
do
that
after
actually
just
can
I
confirm
that
everyone
can
see
this
screen.
Is
it
legible.
I
A
A
We'll
keep
going,
I
can
fit
more
on
the
screen,
so
you
know
the
the
noteworld
is
a
reminder
of
idf
policies,
they're
in
effect,
doing
various
topics
for
this
session
and
affects
various
topics
such
as
patents
or
codes
of
conduct,
and
it's
meant
to
point
you
in
the
right
direction.
A
Exceptions
may
apply
the
idea
of
debating
policy
and
definition
of
an
iedf
contribution
and
participation
has
set
forth
in
bcp
79
if
you're
not
familiar
with
the
noteworld.
Please
do
familiarize
yourself,
but
as
a
quick,
you
know
overview
and
reminder
that
participating
in
the
ietf.
A
You
agree
to
follow
our
processes
and
policies
and
there's
important
things
there
relating
to
you
know
how
you
conduct
yourself
in
the
ietf
and
how
your
contributions
are
recorded
and
distributed
so
it's
important
stuff
and
makes
for
healthy
contribution
into
the
itf
going
back
to
the
agenda,
we're
a
bit
short
of
time
just
due
to
the
recording
stuff,
so
we'll
try
and
keep
the
administrative
year
in
the
wrap
up
as
brief
as
possible
to
go
full
time
to
the
agenda.
I'd
like
some
of
our
other
working
group
meetings.
A
We
don't
have
a
fully.
You
know.
Blow-By-Blow
agenda
here,
there's
going
to
be
a
bit
free-form,
which
is
going
to
be
a
bit
difficult
to
manage,
so
I
would
appreciate
everyone's
best
efforts
in
trying
to
keep
focus
towards
us
finding
an
answer
to
how
to
keep
driving
progress
in
the
vision
negotiation
draft.
That's
effectively
the
purpose
for
this
meeting.
A
We
discussed
this
at
the
quick
interim
at
the
quick
meeting
during
the
last
idf
meeting
and
kind
of
the
broad
high
level
comment
here
is
that
we
have
something,
but
it
seems
maybe
too
complex,
but
what
what
the
needs
are
and
that
we're,
maybe
you're
not
fully
aligned
on
what
the
needs
and
the
opportunities
for
vision.
Negotiation
are
with
some
of
the
opportunities
or
or
possibilities
that
are
on
the
table.
A
There's
in
the
meantime,
there's
been
some
mailing
list
discussion
and
a
discussion
on
github,
and
so
the
broad
outline
we
have
for
this
session.
Is
that
we'll
let
the
editors
of
the
version
negotiation
draft
itself
kind
of
make
some
brief
opening
remarks
and
then
open
the
floor
to
kind
of
anyone.
A
Who's
responded
to
the
mailing
list
to
to
like
or
made
a
comment
somewhere
that
maybe
has
a
strong
opinion
to
give
a
brief
kind
of
high-level
overview
of
some
of
their
ideas
or
some
of
their
themes,
particularly
if
they're
contrasting
with
what
the
document
includes
today
or
or
maybe
present
a
solution
in
that
space
and
based
on
those
kind
of
high
level
overviews
that
the
hope
for
the
chairs
is
that
you
know
we
can
have
maybe
an
open
floor
and
open
issue
discussion
that
can
pick
up
on
those
things,
in
particular
based
on
what
you
guys
and
think
about
this
stuff.
A
So
we
put
out
a
call
for
any.
You
know
actual
concrete
presentations
that
anyone
wanted
to
do.
Watson
kindly
responded
and
asked
for
some
agenda
time,
but,
like
I
want
to
make
clear
we
we
have
time
to
either
go
specifically
over
open
issues.
If
people
think
there's
value
from
that
or
to
discuss
this,
you
know
that's
kind
of
where
we're
at
so.
That
said,
would
anyone
like
to
bash
the
agenda
as
it's
laid
out
here
and
I'll
again
I'll
zoom
in
slightly
make
that
easier
to
read.
A
B
Thanks
lucas,
so
I'm
david
schnazzy,
I
don't
have
any
slides,
so
I
shall
just
briefly
present
some
remarks.
I'm
one
of
the
editors
of
the
virgin
negotiation
draft
along
with
ericoscola.
B
He
had
a
conflict,
so
he
can't
be
with
us
right
now,
but
he
said
he'd
try
to
be
here
for
the
second
half
of
this
meeting,
but
to
quickly
over
go
over
the
history.
If
you
haven't
read
the
draft
or
seen
my
presentation
at
the
last
ietf
that
I'm
not
gonna
go
through
that
entire
presentation.
Again,
we
don't
have
the
time,
but
it
might
be
worth
doing
that
for
you
and
it
does.
B
It
tries
to
explain
what's
in
the
draft
the
concepts
and
the
mechanism,
but
what
we're
here
to
talk
about
today
is
like
really
next
steps.
So
we
presented
this
at
last
etf.
B
So
if
we
can
make
things
simpler,
that's
better
and
so
kind
of
my
reply
at
the
time
was:
let's
hear
more
proposals,
because
I
would
love
to
make
this
simpler,
but
I
just
couldn't
come
up
with
a
way
to
do
that,
and
so,
if
there
are
ways
to
you
know,
keep
the
same
feature
set
and
make
the
proposal
simpler.
No
questions,
let's
just
do
that.
If
there
are
ways
to
reduce
the
feature
set
in
order
to
make
it
simpler,
then
that
becomes
a
trade-off
and
a
discussion.
B
We
should
have-
and
that's
kind
of
why
we're
all
here
today.
So
I
think
that's
all.
I
have
to
say
I'm
gonna
hand
it
off
to
back
to
the
chairs
for
for
to
hand
off
to
folks
who
have
like
actual
proposals
on
how
we
might
be
able
to
simplify
this
all
right.
That's
it
for
me,.
A
E
E
My
preference
goes
to
just
defining
the
incompatible
version,
negotiation
flavor
and
do
nothing
on
the
compatible
version,
negotiation
side
and
the
reason
for
those
I've
said
this
on
the
main
list.
But
there
are
two
ways
of
extending
quick
one
is
by
using
budget
negotiation
packet,
and
that's
the
only
way
to
extend
it,
extend
quick
when
something
other
than
tls
is
being
used
for
the
handshake,
for
example,
noise.
E
E
So
if
somebody
wants
to
implement
compatible
version
compatible
budget
negotiation,
there's
nothing
that
has
to
be
done
at
this
moment
in
quick
viewing
and
we
don't
know
how
a
future
compatible
version
would
look
like
then.
Based
on
that,
I
think
what
we
might
want
to
do
is
what
we
have
to
do.
The
minimum
minimal
thing
that
we
have
to
do
and
that
would
be
to
implement
downgrade
prevention
in
quick
v1
for
incompatible
versions.
A
Thank
you
kazuho.
Would
anyone
else
like
to
take
a
few
minutes
just
to
outline
their
stake
in
the.
I
I
I
I
kind
of
like
the
idea
of
keeping
just
one.
I
was
interested
in
keeping
just
a
compatible
version,
but
casual
makes
a
very
strong
point
that
if
we
have
new
versions,
we
must
probably
be
incompatible
like
if
we
are
going
to
change,
for
example,
switch
from
theorists
to
something
else.
That
definitely
will
be
incompatible
it's
so
I
I
see
this
point.
I
I
I
entered
an
issue
about
the
quirks
of
the
compatible
version
negotiation,
which
leads
to
changing
the
version
number
in
the
long
header
at
a
random
time
in
the
handshake,
and
I
don't
like
that
too
much
because
on
one
hand
it's
a
cue
given
to
third
parties.
That
of
what
we
are
doing
and,
on
the
other
hand,
is
some
kind
of
uncertainty
that
why
am
I
receiving
this
new
version
packet
when
the
negotiation
isn't
concluded?
J
So
yeah,
thanks
in
in
terms
of
the
cutting
one
or
other.
I
I
don't
know
if
it's
premature
to
decide
at
this
point,
but
it's
good
to
know
what
people
are
thinking
on
this
one.
My
my
initial
thought
was
that
the
incompatible
stuff
was
that
was
what
we
had
to
have
and
the
compatible
stuff
was
was
basically
cream.
J
We
we
a
bonus,
and
it
turned
out
that
I
was
convinced,
ultimately,
that
the
that
the
bonus
wasn't
so
much
a
bonus
when
it
came
to
looking
at
how
people
are
going
to
deploy
this,
because
the
the
added
latency
involved
with
the
incompatible
style
of
version
negotiation
leads
to
some
perverse
incentives,
which
might
mean
that
we
have
some
problems
with
deploying
new
versions.
B
Yes,
so
speaking
less
as
editor
and
more
as
just
a
working
group
member
who
has
thoughts
and
opinions,
I
want
to
second
to
second
what
martin
just
said
they're
like
if
we
want
to
remove
some
features.
I
have
to
ask
the
question
like
kazuo
is
suggesting,
for
example,
why
do
we
want
to
do
that?
B
And
you
know
the
answer
I
suspect
is
for
simplicity,
but,
like
martin
was
saying
like
we,
we
probably
need
a
bit
more
deployment
and
implementation
experience
here,
but
I,
my
personal
opinion,
is
that
if
we
go
for
simplicity
at
all
cost,
even
you
know
dropping
many
features.
We
risk.
We
run
the
risk
of
painting
ourselves
into
a
corner
where,
if
let's
say
you
only
have
compatible
or
negotiation,
for
example,
it
means
that
it
prevents
anyone
from
deploying
versions
of
quick
that
are
not
compatible
and
like
at
google.
B
We
have
those,
for
example,
and
if
we
only
go
with
incompatible,
it
means
that
there'll
be.
There
will
be
cases
where
folks
have
to
pay
a
round
trip
and
because
you
know
the
main
selling
point
of
quick
is
latency
not
wanting
to
burn
a
round.
Trip
is
going
to
cost
people
to
go
through
all
sorts
of
contortions
and
do
something
that
is
less
optimal
than
what
they
could
have
done
if
they
had
had
a
compatible
version
negotiation.
B
So
my
my
take
would
be
that
if
we
want
to
remove
some
of
these
features-
and
the
only
argument
is
simplicity-
let's
quantify
the
simplicity
and
see
exactly
what
we
were
saving
here,
both
in
terms
of
standardization
work,
which
you
know
all
lump
in
the
like
analysis.
As
part
of
that,
and
on
the
other
hand,
as
implementation
work,
slash
deployment
costs.
I
think
both
of
those
axes
need
to
be
analyzed
thanks.
E
Thank
you
so
well,
I'm
much
if
we
have
to
choose
one
of
the
two
I
mean,
as
I
said
previously,
not
having
incompatible
version
upgrade
version.
Negotiation
is
going
to
prevent
some
of
us
from
developing
a
new
flavor
of
quick
or
deploying
a
new
flavor
of
quick
compared
to
that
not
having
compatible
version
negotiation.
E
This
moment
doesn't
prevent
anybody
from
implementing
their
own
version
of
own
compatible
version
of
click,
because
they
can
use
transport
parameters
in
the
way
they
want
to
advertise
their
their
application.
J
Yeah,
so
this
is
an
excellent
point
and
there's
there's
a
couple
of
things.
Ryan
points
out
that
the
the
decision
to
punt
compatible
negotiation
is
one
that
we
could
make
very
easily.
J
J
If
you
put
the
compatible
stuff
back
in
again,
and
so
that's
not
not
a
problem
and
because
it
was
kind
of
makes
an
interesting
point,
although
maybe
it
wasn't
exactly
the
point
that
you
made,
which
was
that
for
a
lot
of
people's
use,
cases
compatible
basically
means
making
extensions
to
the
court
protocol
rather
than
changing
the
core
protocol's
meaning,
and
that
is
enough
for
a
lot
of
the
sort
of
immediate
term
use
cases
that
we
have.
C
Lucas,
I'm
gonna,
I'm
gonna
jump
in
here
that
wasn't
the
cube
before
martin,
but
it's
fine
locust
likes
to
ignore
me
anyways.
I
I
want
to
support
what
martin
just
said
in
support
of
what
kazura
said
as
well.
I
was
going
to
I'll
add
one
thing
to
what
martin
said,
which
is
that
I
think
it's
slightly
stronger
than
that.
I
don't
know
here:
do
we
we
can't
define
a.
I
believe
that
we
can
define
a
transport
parameter
that
basically
changes.
What
version
appears
on
the
wire
as
well
right?
C
Is
that
not
the
same
as
what
compatible
version
negotiation
is
like
if
I,
if
I
define
a
transfer
parameter
that
says
every
packet
after
this
point,
once
you've
received
and
acknowledged,
it
is
going
to
be
treated
as
something
else
that
could
certainly
be
the
semantics
associated
with
a
transport
parameter
is
compatible
version
negotiation
fundamentally
different
than
that
martin
you're
saying
that
doesn't
work.
J
Yeah
just
to
quickly
respond
there,
it
doesn't
work
because
of
the
way
that
the
protocol
works
in
zero
rct
and
a
bunch
of
other
things
like
that,
because
you
don't
have
a
clear
demarcation
point
for
saying
the
new
behavior
starts
now
in
in
quick,
and
so
you
can't
you
can't
do
some
things
with
extensions
to
the
protocol.
You
have
to
change
the
version
of
the
protocol
in
order
to
get
the
the
new
behavior.
C
J
C
Parameter
can't
say
that
good
luck
with
that.
J
J
C
You
could
I
mean
that's
so
that's
my
point.
Ultimately.
The
way
I
see
that
is
that
you're
just
signaling
through
a
transfer
parameter
then
call
it
a
transport
parameter.
You
are
verifying
downgrade
protection
through
the
handshake
completion.
So
that's
what
we
do.
Transfer
parameters
anyways.
It's
not.
A
Yeah,
but
thank
thanks
for
that.
We've
got
some
people
in
the
queue
I
just
want
to
remind
people.
This
was
an
opportunity
for
some
opening
remarks
and
then
we'd
like
to
get
on
to
some
of
watson's
slides
to
maybe
we'll
dig
into
this.
So
I'm
not
getting
the
cue
I'd
like
to
keep
the
conversation
flowing,
but
yeah
we
have
some
time.
We
can
come
back
and
forth
to
these
things,
and
with
that
said,
I
believe
it's
kazuho
next
did
I
get
it
right.
A
B
Yeah
just
to
to
address
the
point
of
extensions
versus
version
negotiation,
so
to
be
clear
for
many
things,
extensions
are
the
right
solution.
Let's
say
you
want
to
add
a
datagram
frame.
You
want
to
add.
Timestamps
like
these
are
things
that
are
best
suited
for
extensions,
because
it
allows
you
to
intro
operate
with
an
implementation
that
doesn't
support
your
extension.
You
can
introduce
on
the
base
protocol.
So
that's
a
good
thing
there.
B
However,
if
you
want
to
say
like
change
the
format
of
handshake
packets,
that's
a
different
story
like
so
the
the
idea
there
is.
You
know
you
a
packet
in
quick
is
self-defining
like
you
can
parse
a
packet
by
itself,
and
so,
if
you
want
to
change
the
format
like,
then
you
would
the
distinction
I
would
draw
between.
B
We
will
most
likely
want
to
do
in
this
protocol
later
that
aren't
handled
by
extensions,
and
this
is
what
all
this
is
about,
because
at
the
end
of
the
day
we
could
also
just
declare
failure,
say
quick,
v1
is
the
only
version
of
quick.
B
All
other
versions
are
blocked
on
the
internet
and
I'll
go
home
and
say,
like
you
know,
the
only
thing
we
can
do
is
then
with
extensions,
and
then
you
build
a
version
negotiation
mechanism
inside
extensions
like
tls
did
at
that
point
I
mean
we've
we're
way
ahead
enough
that
we
can
prevent
this
and,
like
we
were
saying
before
the
best
way
to
prevent
ossification
is
to
ensure
that
we
kind
of
exercise
this
this
joint
by
having
a
few
versions.
B
So
if
this
working
group
comes
up
with,
you
know,
version
two
and
three
in
the
next
few
years,
that'll
help
prevent
some
level
of
officification,
so
there
might
be
value
there.
That
is
a
whole
other
tangent,
but
I
think
there
is
an
important
distinction
to
be
had
between
what
can
be
done
with
extensions
and
what
can
be
done
really
should
be
done
by
separate
versions.
A
Thank
you
david.
I
just
got
to
cut
the
key
there.
I
think
we've
got
some
people
in
line,
so
this
seems.
Okay,
I
believe
it's
ryan.
Next.
K
Yeah,
just
to
kind
of
follow
up
on
what
david
was
saying.
If
I
understood
kazuho's
suggestion
correctly,
it
wasn't
to
stick
with
version
one
indefinitely
and
only
make
changes
via
extensions,
or
maybe
that
was
what
he
was
proposing,
but
I
interpreted
to
mean
something
different.
What
I
interpreted
it
to
mean
was
that,
instead
of
inventing
a
new
scheme
for
doing
version
negotiation,
we
use
transport
parameters.
K
As
a
mechanism
of
saying
this
is
the
transport
parameter
that
causes
you
to
switch
to
quick,
v2,
quick,
v3,
quick
v,
whatever
it
is,
we
still
have
the
ability
to
have
different,
quick
versions
on
the
wire,
but
the
mechanism
for
doing
the
negotiation
is
handled
through
transport
parameters,
presumably
doing
this
during
the
handshake
itself
that
that
that
sounds
a
little
bit
challenging,
but
but
certainly
certainly
once
once
we
get
past
the
handshake,
I
think
kazuo's
point
that
doing
compatible
version
negotiation
via
signaling
and
transport
parameters.
K
That
seems
like
a
very
plausible
path
forward
to
me.
B
Could
I
just
quickly
jump
in
to
say
that
that's
not
a
real
distinction?
That
is
what
the
draft
does
today.
The
way
that
compatible
version
negotiation
is
defined
in
the
current
version
of
the
draft
is
built
over
a
transform
parameter.
So,
at
the
end
of
the
day,
it
becomes
a
matter
of
semantics
where
you
can
call
it
whatever
you
want,
but
we
are
using
an
extension
to
trigger
a
version
change.
B
A
Point
thanks
david
christian.
Please.
I
Yeah,
I
mean
the
more
I
think
about
that.
The
more.
What
I
see
on
david's
point
is
that
if
we
want
to
change
the
formats
in
any
significant
way-
and
that
would
be,
for
example,
for
changing
the
format
of
packets
to
do
further
correction
or
changing
the
way
we
do
encryption
or
anything
like
that,
then
we
just
we
don't
just
need
a
negotiation.
I
A
That,
okay,
this
is
a
really
good
discussion.
I
I
I
kind
of
feel
sorry
to
cut
it
off,
but
I
don't
want
to
give
the
opportunity
to
watson
to
go
through
these
slides
if
people
have
thoughts
or
ideas
relate
to
the
slides
or
not
like,
we
have
the
time,
keep
them
in
mind
and
what
we
will
get
to
you.
But
yes,
let's,
let's
queue
this
up,
we've
got
10
minutes
allocated
it's
just
a
short
slight
deck.
It
is
available
on
the
data
track
or
github.
A
If
you
would
like
to
follow
along
at
home,
but
I'm
going
to
share
these
slides
now,
let's
try
and
zoom
in
as
much
as
I
can
or
maintaining.
A
Parity,
I
think
that's
probably
as
best
I
can
do
so
without
further
further
ado
watson.
Would
you
like
to
step
up
to
the
stage
and
direct
me.
L
All
right,
thank
you
very
much.
So
lucas
remembers
the
sequence
of
events,
leaving
this
presentation
a
bit
differently
than
I
do.
I
remember
being
asked
to
oh
remember.
I
think
you
said
three
in
the
morning.
Could
you
expand
on
it
right
have
to
remember
all
right,
so
I
I
have
to
apologize.
I
haven't
been
able
to
follow
the
conversation
that
happened
right
before
this,
and
so
that's
not
reflecting
the
slides
next
slide,
please.
L
So
I
sort
of
want
to
talk
about
what
I
think
we
need,
which
kind
of
informs
the
rest
of
the
presentation.
The
first
property
we
need
is.
We
want
a
no
downgrade
property.
We
don't
want
an
attacker
to
interfere
with
the
version
negotiation
in
a
way
that
leads
to
alice
and
bob
agreeing
on
a
weaker
version.
L
This
is
not
actually
possible
in
full
generality.
If
you
have
a
version
that
is
so
weak
that
the
attacker
can
rewrite
the
transcripts,
then
the
attacker
can
just
use
that
version
on
both
sides,
and
you
have
no
way
of
defending
against
that
you.
You
can
do
something
a
little
bit
stronger
if
you
can
avoid
that
degree
of
weakness.
L
We
also
like
the
best
possible
outcome.
We
want
to
make
sure
the
negotiation
goes
to
quote
unquote
the
best
outcome.
What
exactly
that
means
is
sort
of
up
to
definition,
but
in
particular
you
wouldn't
want
the
server
to
pick
a
worse
choice.
L
Just
and
it's
a
little
like
no
downgrade,
there's
complexities,
not
all
versions
are
going
to
have
compatible
initial
packets,
not
all
initial
packets
work
with
all
the
versions.
The
client
is
willing
to
speak
and
there's
a
latency
cost
to
getting
that
first
flight
wrong.
Also
the
size
of
the
first
flight
matters.
You
can't
just
cram
everything
you
want
into
it.
So
there's
some
tricky
choices
for
clients
to
make
when
they're,
considering
which
version
should
I
try
to
speak
first
to
a
server
alright?
So
let's
go
to
the
next
slide.
L
All
right,
so
this
is,
I
think,
the
central
question
that
leads
to
my
design,
looking
very
different
than
david's
tender,
require
that
you,
a
server,
can
always
extract
a
list
of
supported
versions
from
any
initial
packet.
If
we
can
require
that,
then
the
server
can
just
pick
the
one
it
wants
to
speak.
L
If
we
don't
require
that
if
we
can
just
look
at
if
we
can
just
look
at
the
initial
packet
version
number
and
see
that
we
don't
speak
it
and
suggest
a
list
for
the
client
to
pick
from,
then
that's
a
lot
more
complicated
because
now
there's
potentially
multiple
trips
and
it's
a
mess.
L
So
let's
assume
for
the
rest
of
the
presentation
that
they're
in
the
first
case,
no
matter
how
nasty
the
initial
packet's
going
to
be
no
matter
how
different
it's
going
to
be.
It's
always
going
to
be
the
case
that
the
server
can
pull
out
a
list
of
version
numbers
all
right
next
slide.
Please.
L
There's
a
version
number
except
there
is
now
a
version
number
extension
and
before
the
client
could
only
offer
a
range
of
versions
indicated
by
its
by
its
version
number
the
clients
that
we
have
the
list
of
versions
the
server
picks
and
sends
in
the
response,
what
version
it's
going
to
use-
and
this
is
then
part
of
the
hand,
script
hint
handshake
transcript
in
a
way
that
never
collides
and
that's
enough
because
then,
if
the
attacker
was
to
modify
the
versions
or
the
selection,
things
would
break
and.
L
That's
let's
scroll
down
so
next
slide.
Please
all
right!
So
here
are
some
of
the
problems
and
then
they're
all
grouped
under
compatibility.
So
the
first
kind
of
compatibility
problem
isn't
much
of
a
problem.
It's
the
client
might
speak
two
versions
and
they've
sent
the
first
flight.
It's
only
compatible
with
a
more
commonly
supported
version.
L
The
harder
one
is
client
thinks
it
can
speak
both
these
versions.
It
actually
can't
for
some
reason
and
its
first
flight
is
only
compatible
with
one
of
the
versions
it
advertises.
Not
the
other
then
the
hardest,
because
in
some
sense
means
the
client
could
end
up
speaking
something
it
never
intended.
Is
the
client
says?
Oh
I
support
x
and
y,
and
I've
just
sent
you
a
perfectly
fine
opening
flight
for
x
and
the
server
goes
and
looks
and
says.
Actually
you
sent
me
a
perfectly
fine
fight
flight
for
why
let's
go
ahead
and
use
it?
L
The
next
slide.
Please.
L
Tentative
solution
so
easy
case
doesn't
really
matter.
You
either
go
ahead
speaking
x
or
you
tell
the
client.
Actually
I
want
you
to
try
again
with
version
y
and
when
you
try
again
with
version
y
everything
you
know
it's
the
same
same
set
of
version
numbers
being
advertised,
there's
no
difference
between
network
of
streaming
compatible
and
incompatible
ones.
Just
goes
long
or
the
server
says.
Okay,
you
know
what
I'm
happy
with
version
x.
I
don't
want
to
take
the
latency
head,
I'm
just
going
to
go
ahead
and
we'll
speak
x
in
the
harder
case.
L
L
Okay,
maybe
it's
not
so
easy,
but
yeah
hardest
case
version,
one!
So
don't
do
it
don't
be
in
a
situation
where
you
can
accidentally
end
up
sending
an
initial
flight,
that's
more
compatible,
which
means
that
the
version
y
has
to
define
the
ver
the
flights
that
are
compatible
within
an
easy,
consistent
way
across
the
implementation.
So
if
you
don't
have
that
you'll
have
the
problem
that
two
sides
will
start
talking
and
they're
going
to
disagree
about
what
about
the
meaning
of
what
they
sent
in
the
first
round.
L
All
right
for
those
of
you
who
play
bridge
you'll
recognize
why
I
called
sort
of
recognize
these
things.
L
Okay,
speaking
with
that's
compatible,
they'll,
probably
pick
the
one
they're,
okay
speaking
with
rather
and
go
through
a
round
trip,
there's
two
sorts
of
solutions:
the
first
one
I
I
called
cycle
advertise,
desired
versions,
the
http
service
or
something
else
and
remember
them
for
server.
L
This
is
so
basically
you
get
tipped
off
what
you're
going
to
want
to
speak
magically
outside
the
bounds
of
the
protocol.
You
you've
been
given
extra
information,
whether
it
be
a
dns
or
all
service
header.
The
other
one
is
after
we've
negotiated
this
quick
handshake.
There's
no
reason
that
we
can't
start
negotiating
the
next
one,
so
we
can
say
okay.
L
Well,
we
have
this
connection,
but
actually
I
would
have
liked
it
better
if
you
had
come
in
with
version
why
in
the
beginning,
could
you
please
set
up
a
version
y
connection
and
all
your
other
requests
can
go
over
that
this
is
a
bit
messy.
If
there's
a
state
between
them,
there
shouldn't
be
much
state
between
them
that
that
gets
affected.
But
then
you
can
start
moving
over
newer
requests
onto
this
new
channel.
You
have
set
up
so
this
addresses
the
question
of
okay.
L
Well,
everybody
in
the
world
speaking
version,
one
client
and
a
server
would
like
to
speak
version
two,
but
they
don't
want
to
spend
the
latency
penalty
of
having
to
go
back
to
one
if
they
start
if
they
start
off
with
two
or
it's
too
big
to
start
off
with
within
compatible
with
both
next
slide.
Please.
L
So
the
other
big
thing
is:
we
should
try
very,
very
hard
to
make
the
problem
simpler
and,
if
you're
doing
a
lot
of
things
with
extensions,
so
I
think
you're,
sort
of
a
conversation
that
can
do
everything
except
redesign
the
initial
packet
that
that
that's
a
little
bit
easier
to
do,
because
then
you
don't
have
to
go
through
the
version
negotiation.
It's
not.
The
work
is
hard,
also
there's
a
few
versions
and
they
have
a
common
ordering.
L
So
everybody
agrees
that
one
is
that
that
two
is
better
than
one
or
there's
an
experimental
version
that
we
sort
of
want
to
try,
but
we're
happy
speaking
the
other
one.
Because
then
you
don't.
You
know
the
mechanism
should
generalize
a
bit
beyond
that,
but
I
think
this
covers
most
of
the
cases
where
you
really
want
to
have
the
aversion
negotiation
system
work
next
slide
is,
I
think,
the
last
one.
A
Yeah
thanks
thanks
watson,
good
timing.
There
we're
just
about
time
for
the
the
slides,
but
let's
just
take
the
questions,
and
I
think
that
can
lead
into
the
natural
ebb
and
flow
of
discussion.
So
we
did
have
mike
in
the
queue
just
before
I
cut
it,
but
david's
in
there
now
he's
giving
a
thumbs
up,
let's
go
with
mike
and
then
we'll
go
to
david.
D
D
B
Thanks
thanks
for
the
presentation
watson
so
on,
I
have
to
admit
sorry,
I
I
got
kind
of
confused,
and
so
I
I
have
a
really
hard
time
understanding
what
you're
actually
proposing
it
doesn't
help
that
I
haven't
played
bridge
in
over
a
decade,
but
so,
when
you
say
the
https
record,
I
just
want
to
like
clarify
here.
This
isn't
for
http
3..
B
B
You
do
not
need
any
kind
of
version
negotiation,
because
the
out-of-band
mechanism
already
tells
you
tells
the
client
all
of
the
versions
supported
by
the
server.
So
the
client
is
going
to
use
the
correct
version
from
the
get-go.
The
the
problem
we're
trying
to
solve
for
here
is
for
other
protocols
that
you
just
you
know.
All
you
have
is
a
host
name
and
a
port,
and
you
want
to
do
quick
to
them
and
you
don't
know
which
version
of
quick
they're
speaking.
So,
unfortunately
we
can't
use.
B
I
mean
if
we
have
https,
then
we
can
all
back
up
and
go
home.
The
problem
is
already
solved,
but
then
kind
of
going
into
more
detail
and,
like
I'm
sorry,
if
I'm
the
only
one
misunderstanding
here,
but
your
proposal
doesn't
sound
any
different
from
what's
in
the
draft
to
me,
and
I
think
that's
just
because
I'm
not
understanding
what
your
proposal
is
like
if
you
had
a
packet
diagram
or
something
you
know
like
what
do
you
put
in
the
transfer
parameters?
That
would
help
me
immensely.
L
L
B
A
Thanks
david,
I
think
it's
echo
next
in
the
queue,
so
please
go
ahead.
M
Yeah
hi
watson
so
serious.
It
seems
to
me
that
there
are,
you
know
as
far
as
going
back
to
requirements
here,
which
is
the
like
you're,
so
so
I
mean
first
of
all,
like
we
have
this
concept
like
compatible
and
compatible,
and
they
think
that
you
just
said
the
same
thing,
which
is
like
that
the
initial
and
the
version
numbers
have
to
be
have
to
be
understandable.
Right.
M
So,
as
I
understand
your
design,
if
the,
if
the
client
is
wrong
about
what
versions
the
server
supports
and
the
versions
are
like
radically
different,
like
I
don't
know,
one
is
like
you
know:
one's
a
one's,
the
ones
complement
of
the
other
or
something
you
know.
Then
then
then
then
you're,
then
you
think
just
chokes
right.
L
L
M
Okay,
so
I
think
the
okay
so
okay,
so
I
think
so.
If
I
understand
what
you're
proposing
then
is
you're
proposing
to
to
do
without
compatible
what
we
call
a
compatible
negotiation,
which
is
to
say
that
if
the
server's
client's
flight
is
valid,
then
the
server
accepts
that
version
and
says
by
the
way.
M
I
prefer
you
reconnected
with
version
another
different
version,
but
there's,
but
there's
no
way
that
the
connection
doesn't
upgrade
itself
like
tls
and
and
that
that
and
then
and
then
and
then
in
the
case
where
it's
incompatible,
you
have
a
somewhat
different
mechanism
for
handling
the
downgrade
attacks,
which
I
have
to
think
through
is
am.
L
So
I
I
think
the
question
is
what
does
compatible
mean
here
so
in
tls,
as
of
1.3,
the
the
client
is
listing
the
supported
versions
and
there's
extensions
and
those
extensions.
A
a
1.2.
Only
server
will
look
at
at
the
advertised.
We'll
look
at
the
the
version
it's
getting
in
the
client,
hello
and
say:
okay,
I
only
speak
1.2.
L
It
will
then
look
at
the
extensions
and
extract
the
information
for
the
1.2
handshake
and
continue
on
its
merry
way
and
the
client
will
follow
if
it
supports
1.2
as
well,
and
if
it's
a
1.3
server
it'll
look
for
different
extensions
or
maybe
some
of
the
extensions
are
shared
and
come
up
with
the
information.
You
need
to
continue
the
1.3
handshake
and
continue
on
its
merry
way
and
it,
but
they
both
are
using
the
same
extension
for
the
versions
that
are
advertised.
M
I
concur,
and
so
I
guess
my
question
is
in
your
design
as
I
understand
it,
if
I
send
there's
no
way
for
me
to
send
a
initial
to
be
valid
for
v1
and
v2.
Instead,
I
send
a
initial
for
v1
and
the
server
says
great
v1,
but
I
wish
you
offered
me
v2
when
I
reconnect
is
that
correct.
L
M
Our
terminology
is
compatible,
which
is
to
say
that
the
you
can
send
a
client
hello,
which
is
valid
for
two
versions,
and
the
server
can
pick
either
one
and
incompatible
means
the
services
I
have
nobody
you're
talking
about.
I
would
speak
these
versions
come
back
with
something
something
else
that
I
would
accept.
So
I
mean
I,
I
see
martin
dukes
in
the
cube,
but
I
guess
I
would
just
like,
but
there's
some
interesting
ideas
here.
M
So
so
I
don't
want
to
detour
too
much,
but
that,
like
most,
the
complexity
in
the
david's
in
my
draft
is
in
handling
the
incompatible
version
negotiation.
The
compatible
is
actually
very
straightforward,
though
perhaps
it
creates
a
bunch
of
a
bunch
of
new
requirements
you
have
to
process,
but
most
of
the
complexity
is
about
like
convincing
yourself
that
the
incompatible
negotiation
we
didn't
have
attacks
on
the
negotiation
mechanism.
A
J
So
it
took
me
a
while
to
get
my
head
around
this
one,
but
when,
when
watson
you
said,
the
cost
of
this
is
that
the
server
needs
to
be
able
to
pull
the
information
out
of
the
the
initial.
J
I
want
to
just
unpack
that
a
little
bit,
because
I'm
not
sure
that
I'm
following
does
this
mean
that
we
need
to
change
the
protocol
such
that
a
an
incompatible
version,
so
a
server
that
speaks
an
incompatible
version
can
read
that
incompatible
version,
at
least
to
the
extent
that
it
understands.
What
versions
are
the
client
supports.
J
Does
this
mean
that
some
that
the
tls
implementations
have
to
implement
the
noise
protocol,
to
the
extent
that
the
that
they're
able
to
extract
this
information
from
that
protocol,
or
or
vice
versa?
That's
that's
the
question.
L
So
I
I
I
realize
now
that
this
probably
means
we
have
to
go
change.
We
have
to
go,
add
adding
variant,
add
just
enough
invariant
that
you
can
get
to
the
version
information
the
same
way
across
versions
just
like
in
tls,
where
we
have
extension
format.
We
can
never
change
the
extension
format
now,
because
we
have
to
at
least
keep
the
signal
that
we're
changing
the
extension
format
in
the
same
place
and
the
versions
ahead
of
that.
J
N
Yeah
thanks
watson
for
the
presentation,
so
I
mean
I
I
think
yeah
I
mean
to
reiterate
what
mp
said.
I
think
we're
a
little
down
the
road
where
we've
kind
of
assumed
that
the
end
packets
would
be
at
least
part
of
the
foundation
of
version
negotiation.
N
Now
now
crystallize
that
in
the
standard-
and
I
am
not
prepared
to
make
the
assumption
that
that,
like
initials,
will
remain
decipherable
for
all
time
beyond
the
invariants,
which
are
just
the
the
single
long
header
bit
and
the
version
field
and
the
cids,
because
now
we
may
eventually
need
to
if
we
do,
if
we
do
see
ossification
around
the
version
people
may
need
to,
we
may
need
to
have
some
sort
of
transport
parameter,
based
negotiation
mechanism
and
so,
like,
I
think,
compatible
vn
is
important
for
that
reason,
but
ultimately,
I'm
not
really
prepared
to
abandon
the
version
field
as
a
technique
to
do
this.
N
Secondly,
like
I'm
not,
I
think
there
are
ways
to
do
compatible,
vm
that
don't
have
this
problem.
But
from
what
I
understand,
your
presentation,
I'm
a
little
concerned
that
a
plain
old
b1
server
is
just
going
to
send
vn
packets
when
it
gets
weird
version
numbers
and
won't
know
about
the
transport
parameter
and
I'm
not
really
sure
how
that
will
play
out.
L
N
Yeah
so,
like
I
mean
tls
has
a
lot
more
invariance
to
it
at
least
implicitly,
you
don't
have
an
invariant
draft
as
far
as
I
know,
but
you
know
there's
a
lot
of
stuff:
that's
going
to
be
baked
into
any
conceivable
version
of
tls.
As
I
understand
it,
so
I
mean
I've
been
resisting.
The
early
grammar
is
going
to
I'm
just
going
to
drop
it.
N
I'm
just
going
to
mention
it
anyway
because,
like
I
have
that
version
of
alessin
draft,
which
has
not
been
adopted
by
anyone,
but
I
did
presented
a
couple
iatfs
ago
and
the
basic
idea
there
is
to
make
initials
secure,
like
actual
actually
confidential
and
so
like
to
have
a
mutually
compatible
mutually
readable
by
everyone.
Initial
is
like
is
completely
you
know,
hostile
to
that
to
that
intent.
I
I
Yes,
let's
say
that
I
have
a
lot
of
argument
with
martin,
the
duke
there.
I
I
I
B
Yes,
so
thanks
for
this
discussion,
I
think
I
understand
your
proposal
a
lot
better
now,
watson,
so
yeah.
I
think
some
folks
have
isolated
some
of
the
problems
with
it
already,
but
I
want
to
kind
of
address
the
the
crux
of
the
issue
and
the
main
motivation
for
you
to
write
it.
In
what
way
is
this
proposal
simpler
than
the
one
that
we
have
in
the
draft
today.
L
You
don't
have
to
go
back
and
re
so
in
the
draft
today
there
or
sorry.
So
I'm
not.
I
haven't
looked
closely
at
the
draft
today.
As
I
remember
the
presentation
I
have
looked
at
a
draft,
but
I
don't
really
I'm
not
that
familiar
with
it.
Yet
there's
a
bunch
where
there's
re-encoding
of
how
many
times
have
we
tried
to
do
version
negotiation
before
was
the
server
advertised
those
previous
times
etc,
and
with
my
proposal,
its
own,
the
clients
always
saying
the
same
thing.
L
What
it
supports
and
so
one
benefit
is
you
only
ever
go
back
once
it's
only
ever
so
I
I
think
you're
misunderstanding.
B
What's
in
the
draft,
then
the
there's
never
a
notion
of
going
back
multiple
times.
The
only
thing
that
is
like
slightly
simpler
than
yours
is
the
way
we
authenticate
the
version
negotiation
packet,
except
because
that
isn't
the
invariance.
B
Your
proposal
is
like
not
possible
because
we
can't
violate
the
invariance,
and
so
what
we
have
in
the
draft
is
like
when
you
get
a
version,
negotiation
packet
and
you
want
to
do
incompatible.
You
say
by
the
way
I
received
this
version
negotiation
packet
and
unless
I'm
mistaken,
because
you
can't
modify
the
vm
packet
itself
because
of
the
invariance,
the
only
possible
way
you
can
make
sure
that
that
packet
wasn't
tampered
with
is
by
putting
something
of
it
into
a
packet.
B
L
If
we
really
can't
add
the
little
bit
of
structure,
if
we
either
aren't
happy
with
only
ever
advertising
a
contiguous
range
of
versions
from
v1
to
what's
in
the
version
number,
because
that
would
work
that
would
that
would
work
with
the
and
you're
just
sending
that
I
was
encoding
than
v2,
then
yeah,
you
can't
actually
send
all
the
versions
you
support
in
the
first
flight
all
the
time,
and
so
we
have
to
have
that
more
complicated
thing
where
we're
saying
oh
I've
seen
this
vn,
etc,
etc.
B
Yeah-
and
I
think
you
know,
based
on
the
way
quick
was
designed,
where
versions
are
32-bit
and
not
contiguous,
I
think
you
know
this
is
just
the
world
we
live
in
cool.
Thank
you.
M
Yeah
hi
folks,
so
I
think
it
sounds
like
we've
sort
of
like
deviated
a
little
bit
from
the
what's
the
presentation
which
so
I'm
just
gonna
continue
with
that
vain.
Unless
the
chairs,
unless
lucas
tells
me
to
stop
so
thanks
lucas,
so
I
think
like
it
would
be.
M
I
thought
we
sort
of
had
consensus
on
like
what
we're
trying
to
accomplish,
but
I'm
I'm
hearing
a
lot
of
discussion
now
about
like
what
we
are
trying
to
accomplish
and
and
and
to
the
extent
to
which
that
is
true
and
there's
a
senate
about
that.
Perhaps
answers
all
those
questions
about
what
you're
trying
to
accomplish.
In
particular,
I've
heard
people
suggest
we
don't
need
compatible
other
position
only
incompatible.
M
I
sure
don't
wonder
if
we
need
to
either
so
so
I
think
that
would
be.
That
would
be
useful
to
to
get
clarity
on.
I
also
just
as
a
note
you
know,
while
the
invariants
are
in
various
they're,
not
invariant,
because
they're
not
in
rsa,
and
so,
if
we
discovered
the
events
were
wrong,
we
actually
still
could
change
them
so,
but
I
think
again,
I
I'd
encourage
the
church
like
help
us
to
get
to
the
classes
of
like
what
we
actually
needed.
M
I
am
not
really,
frankly,
I'm
not
persuaded
by
the
argument
from
these
sort
of
protected
initial
messages
that
we
need
virtual
negotiation.
The
purpose
of
version
negotiation
is
to
recover
from
a
misunderstood
initial
message
and
that
that
seems
to
be
the
obvious.
This
is
this
is
are
largely
intended
to
be
are
largely
intended
to
conceal
the
content.
Initial
message
and
falling
back
to
the
unprinted
initial
has
the
impact
of
revealing.
M
What's
in
the
initial
message,
it
seems
to
me
that,
having
a
way
to
say
actually,
I
wish
you
guys
sent
me
that
protective
thing
kind
of
defeats
much
to
the
point,
and
rather
there
should
be
recovery
mechanisms
protected
like
until
like
an
ech
or
ultra
hard
fail.
So
I'm
not
persuaded
that
that
produces
an
argument
for
first
negotiation.
A
Yeah
thanks
hecker,
some
of
the
stuff
you
said
there
I
think,
is
kind
of
echoing
some
of
the
commentary.
I
can
see
in
the
chat
about
trying
to
understand
our
requirements.
You
know
to
be
clear
now
you
know
what
watson's
proposal
is
this.
You
know
a
sample
point
in
this
whole
discussion,
and
so
I
think
it's
fine
to
for
us
just
to
carry
on
here.
A
I
think
I
think
it
is
hard
you
know
for
someone
not
deeply
involved
in
the
vn
stuff
today,
such
as
myself,
like
understanding
these
trade-offs
is
difficult,
like
I
don't
have
a
strong
opinion
in
whether
it's
incompatible,
supported
or
or
not
or
both
or
none.
I
I
think
I
don't
know,
I
don't
know
how
how
we
we
get
to
that.
Obviously,
there's
some
people
here
who
are
interested,
otherwise
they
wouldn't
have
shown
up
but
yeah,
take
a
vote.
That's
not
what
we
do.
J
You
seem
to
be
struggling
with
the
lucas.
I
I
guess
the
the
problem
here
is
that
we
just
had
an
impassioned
argument
for
one
and
then
we
had
an
impassioned
argument
for
essentially
the
diametric
opposite
of
the
same,
and
I
don't
think
we
have
any
basis
for
deciding
whether
one
option
or
the
other
option
is
necessary
or,
as
the
draft
would
have
it,
why
not
both
with
the
obvious
consequences
for
that?
So
I
think
we
should.
J
We
should,
probably
you
know,
get
a
real
sense
from
people
about
what
their
their
priors
are
on
on
the
the
two
main
features
here.
Do
we
want
echo
says
violently
apathetic
that
sounds
about
right?
I
do
people
want
to
have
versions
of
quick
that
are
so
mutually
indecipherable
that
they
they
can't
be
recognizable
from
the
other
one.
So
do
do
you
want
to
have
incompatible
versions.
Is
is
a
question
that
I
would
ask,
and
maybe
we
can
start
with
the
simple
question.
A
Thanks,
I
I
see
david
was
quick
to
join
the
queue
as
well
after
that
so
yeah.
Please
go
ahead.
B
So,
just
in
terms
of
proposing
new
ways
to
go
forward
and
feel
free
to
tell
me
you
disagree,
we
have
a.
We
have
a
working
group
draft
here
that
addresses
two
problems
like
we
said
compatible
and
incompatible,
and
we
have
seen
that
there
are
folks
who
really
need
one,
and
then
we
have
folks
who
say
that
they
really
need
the
other,
I'm
in
general,
very
much
in
favor
of
not
having
something
that
you
know.
Why
not
both.
B
But
in
this
case
we
have
a
good
reason
to
do
that
in
that
they
enable
very
very
different
things
and
to
be
fair,
it's
true
that
we
could
split
those
into
two
separate
extensions
as
opposed
to
having
them
once
honestly,
given
that
they
would
probably
need
to
have
the
same
information,
it
seems
natural
to
put
them
together,
but
that
we
can
have
it
either
way.
B
That's
not
a
problem,
but
I
think
you
know
why,
like
in
my
opinion,
this
effort
has
stalled
at
the
last
itf,
because
multiple
people
came
up
to
say
that
this
was
too
complicated
and
we
have
yet
to
see
a
single
like
fully
fledged
functional
proposal
that
is
simpler,
and
so
I
would
say
at
this
point
you
know
I
would
let's
move
this
forward.
There
are
people
who
are
interested.
There
are
people
who
need
this
if
you're
not
interested,
you
don't
need
to
implement
this.
B
This
is
an
extension,
so
I
would
just
propose
we
move
forward
with
this.
Unless
someone
has
another
like
an
actual
proto
like
fully
fledged
proposal
where
we
actually
see
the
water
format
and
see
how
it
handles
multiple
these
cases,
but
until
then,
I'm
like
no
longer
really
interested
in
like
humoring
the
this
is
too
complicated.
If,
but
we
still
need
everything
it
does,
and
we
don't
know
how
to
make
it
simpler.
That's
not
getting
us
anywhere.
Unfortunately,
thanks.
A
Yeah
thanks
david-
I
I
do
you
know
just
as
a
chair's
perspective
here.
I
do
agree
with
some
of
those
points
that
it
seems
in
a
slightly
cyclical
argument
of
you
know.
What
do
we
want?
When
do
we
want
it
now?
What
is
it?
No?
That's
too
much,
so
it's
not
great
anyway.
That's
just
my
opinion.
It's
a
bit
late
here
and
I'm
a
bit
tired.
Let's
go
to
kazuo,
please.
E
On
the
other
hand,
regarding
compatible
version
negotiation,
as
I
said,
I'm
convinced
that
you
know
we
have
to
decide
now
and
I'm
also
not
sure
if
we
have
enough
information
to
design
that,
because
let's
say
that
we
design
v2,
it
could
be
the
case
that
we
want
to
send
the
two
specific
parameters.
Homestead
version
indication,
then
that
means
that
it
would
be
preferable
to
define
a
transport
parameter
specific
to
v2
that
advertises
support
or
v2,
as
well
as
carrying
those
parameters.
E
A
Kazuho
ryan,
please.
K
Yeah
ecker
asked
a
provoking
question
about
whether
we
needed
incompatible
version
negotiations,
specifically
whether
we
would
ever
want
to
have
two
versions
of
quick
that
were
sort
of
mutually
incomprehensible,
and
I
just
wanted
to
observe
that
during
the
development
of
quick,
there
were
certainly
multiple
times
over
the
years
that
the
protocol
existed,
where
we
made
utterly
incompatible
changes
to
the
protocol.
K
It's
certainly
conceivable
that
maybe
at
some
point
in
the
future,
we
we
won't
need
to
make
changes
like
that
anymore,
but,
but
certainly
we
sort
of
already
have
an
existence.
Proof
I
think
for
that
functionality.
So
I
would
be.
I
would
be
love
to
to
rule
that
out.
C
C
I
see
it
it's
basically,
we
could
use
transport
parameters,
but
wouldn't
it
be
nice,
if
that's
really
how
I
see
it
and
and
it's
it's
it's
it's
convenient
to
be
able
to
do
it,
given
that
we
already
have
the
mechanism
of
transport
parameters
to
use
that
to
do
compatible
version
negotiation,
but
really
the
semantics
of
this.
The
way
I've
read
it
so
far
are
basically
definable
through
any
transport
parameter.
C
The
whole
point
of
version
equation
for
me
is
when
you
can't
actually
get
to
that
point
of
talking
to
each
other,
and
we
say:
okay,
we
have
to
agree
first
on
how
we
talk
to
each
other
and
that's
incompatible
version
negotiation
because
they're
incompatible,
you
need
version
negotiation.
If
you're
already
talking,
you
can
figure
out
a
million
ways
of
talking
about
what
you
want
to
talk
about.
Next,
that's
perfectly
reasonable
and
fine,
but
it's
not
the
hard
problem.
But
it's
not
the
interesting
problem
to.
A
M
Yeah
so
like
I'm
not
going
to
lie
down
the
road
over
this,
but
like
this
all
seems
like
frankly,
pretty
like
unmotivated,
so
the
like,
we
have
lots
of
examples.
Protocols
and
compatible
with
each
other,
ssh
and
tls
are
compatible
with
each
other,
but
we
don't
have.
We
don't
have
like
a
mechanism
where
you
connect
an
ssh
server
and
it's
otherwise.
M
You
spoke
dls
because
no
one
has
a
problem,
because
you
know
exactly
what
the
server
speaks,
and
so
the
question
at
hand
is
not
do
we
need
to
have
two
incompatible
versions
of
quick
that
can't
touch
each
other.
The
question
is,
we
have
a
situation
in
which
the
client
is
so
ignorant
of
the
search
capabilities
that
it
has
to
send
a
has.
It
has
to
send
a
message
like
that
might
be
unacceptable.
The
server
and
server
might
reject
it
and
say
try
to
turn
it
away,
and
that
is
a
that's
a
bit.
M
It's
a
much
much
much
more
unusual
case,
and
it's
not
a
case
we
generally
ever
designed
for,
and
so
the
you
know.
I
I
heard
what
ryan
was
saying
and
I
understand
what
he's
saying
about
having
different
versions
of
quick
but
like,
but
even
in
even
the
case
ryan's
talking
about
barham.
You
know
that
that
you
could
get
like
a
very
large.
M
As
I
recall
this
conversation,
the
clients
only
spoke
actually
one
version
of
quick
anyway,
and
so
what
actually
happened
was
the
the
the
clients
would
just
say
the
servers
would
say
no
and
the
client
would
come
back
with
tls,
as
opposed
to
coming
back
with
my
quick
version
plot.
So,
but
it's
certainly
it's
a
reasonable,
viable
story
in
any
case,
so
so
yeah.
I
I'm
not
really
persuaded
that.
M
We
need
the
clients
to
be
that
that
flexible
in
this
matter
with
that
said
again,
I'm
not
really
gonna
lie
down
on
the
road
over
this,
but
I
do
think
we
need
to
distinguish
between
these
cases
where
client,
ignorance
and
these
cases
of
we're
trying
to
like
shield
the
client
version
number
from
or
information
to
client
hello
from
attackers,
because
it's
not
clear
to
me
that's
the
same
solution.
A
Thanks
saka,
just
as
a
chair
interject
that
are
there
some
of
those
cases
that
you
describe
are
they
like
actually
documented
somewhere
like
are
we?
Are
we
agreeing
on
the
kind
of
classification
of
problems
that
would
people
are
trying
to
solve?
This
isn't
just
directed
to
yuraka
but
but
kind
of
to
people
in
general?
I'd
be.
H
I
I
Well,
I
mean
I
I'm
listening
and
I
I
think
that
we
need
to
make
progress.
I'm
looking,
I
have
been
looking
at
david
straft
and
the
device
proposal
I
mean.
I
don't
think
that
those
drafts
are
too
honest
to
implement.
I
mean
if
we,
if
we
want
to
implement
that
we
could-
and
I
could
probably
be
done
and
implement
that
in
pico,
quick
in
maybe
a
week
from
now,
so
that
that
by
itself
I
don't.
I
agree
with
david
that
the
complexity
argument
is
weak.
I
I'd
like
to
have
some
practice
on
the
idea
of
changing
a
version
number
midstream,
which
is
what
is
proposed
in
a
compatible
version.
I
am
skeptical
of
that
because
I
mean
the
chances
there
of
chipping
on
your
own.
Shoelaces
are
quite
high,
but
that's
that's
the
kind
of
stuff
that
we'll
find
with
interrupt
trials,
and
I
I
do
believe
that
on
that
basically
not
having
incompatible
negotiation
will
be
a
commitment
to
only
do
tls
forever.
I
A
You
skipping
over
a
lot
of
chat,
which
is
good,
keep
it
coming.
We
have
ryan.
K
Yeah
I
wanted
to
follow
up
on
what
ecker
said.
It
is
certainly
true
that,
during
the
most
of
the
time
that
chrome
was
speaking,
quick
in
production,
it
did
not
exercise
the
version
negotiation
mechanism.
That
is
true.
It
is
not
true
that
the
version
negotiation
mechanism
was
never
used.
In
fact,
google
internal
health
checking
tools
that
check
the
health
of
quick.
Do
precisely
that,
so
so
that
mechanism
very
much
has
been
used.
K
That
being
said,
what
I
I
may
be
mischaracterizing
what
I
think
I'm
hearing,
but
what
what
I
think
I'm
hearing
is
a
large
number
of
folks
that
feel
there's
a
need
for
incompatible
version
negotiation
and
a
set
of
folks
like
ecker,
who
think
we
probably
don't
need
it,
but
aren't
willing
to
lie
down
in
the
road
to
to
use
his
words.
To
me.
That
sounds
an
awful
lot
like
rough
consensus
to
move
forward
on
trying
to
solve
incompatible
version
negotiation.
A
Thanks
ryan
david
next,
please.
B
No
I'm
just
laughing
because
people
are
queuing
up
to
die
on
hills
and
lie
on
tracks,
where's,
dimitri,
when
you
need
him.
So
just
I
wanted
to
add
one
point
like
specifically
about
incompatible
version
negotiation.
B
The
I
go
raised
a
really
good
point
that
for
a
lot
of
things
that
are,
you
know,
tls
based
we're
going
to
want
most
likely,
maybe
not
always,
but
most
likely
most
often
something
compatible,
because
I
fully
expect
quick
v2
to
look
a
whole
lot
like
quick,
v1,
not
necessarily
always
but
mostly,
but
on
the
topic
of
and
and
then
you
know,
there's
a
whole
other
class,
which
is
you
know.
Let's
do
use
the
ssh
key
exchange
over
quick.
B
We
should
totally
build
a
version
of
ssh
real
quick
that'd,
be
cool,
but
there's
I
don't
foresee
a
use
case
where
a
client
is
gonna
say
I'm
debating
between
tls
and
web
pki
and
ssh.
Like
that's
not
a
thing.
Those
are
two
different,
completely
different
things,
and
so
in
for
those
cases
like
they're,
you
wouldn't
be
having
the
same.
B
The
two
on
the
same
connection-
and
I
think
this
also
applies
to
noise-
there's
a
there's,
a
cool
proposal
about
how
to
use
the
noise
key
exchange
and
quick,
and
I
think
there
are
use
cases
where
that's
great
but
you're
not
going
to
be
loading
a
web
page
over
that
because
for
a
web
page
you
want
the
web
pti.
B
B
They
both
use
tls
certificates
and
that
are
backed
by
the
web
pki
for
loading
web
pages,
but
the
key
exchange
protocols
are
incompatible,
and
so
we
actually
do
have
this
in
production.
Today,
chrome
supports
itf,
quick
draft
29
and
google
quick
crypto
version
50.,
both
of
which
are
backed
by
the
same
certificates,
the
same
pki
but
are
have
no
hope
of
being
compatible.
B
B
I
wouldn't
exclude
that
five
years
down
the
road
we
decide
to
build
a
new,
quick
key
exchange-
that's
not
tls!
Maybe
we
won't
make
your
baby
ecker
will
lie
down
in
the
road,
but
we
should
have
that
option
open
to
us.
So,
specifically,
that's
kind
of
why
I
really
care
about
version
negotiation
and
then
on
the
topic
of
why
I
really
care
about
compatible
version
negotiation
just
to
quickly
summarize
points
that
have
already
been
made.
B
If
we
force
people
to
burn
a
round
trip,
they
won't
use
this
and
they
will
do
things
that
are
unideal.
So
I'm
hearing
a
lot
of
support
from
folks
who
want
either
one
or
either
the
other
or
they're
both
are
are
folks.
Gonna
lie
down
in
the
tracks
to
say
that
the
other
one
must
not
be
in
these
documents.
A
Thanks
david,
I
think
that's
a
very
good
question
and
I
ask
people
to
to
think
about
it
and
respond
if
they
want
to.
But
for
the
time
being
we
have
ekka
in
the
queue.
So
please
step
on
up.
M
Yeah
I
mean,
I
think,
like
I
don't
agree
with
everything
david
just
said,
but
I
do
think
that
it's
important
to
have
compatible
for
the
same
reasons
that
david
indicated,
which
is
that
it's
going
to
be
like
a
lousy
if
we
can't
make
any
change
whatsoever
that
involves
the
version
number
without
taking
a
round
trip
head
and
so
and
given
that,
like,
like
99
of
the
complexity
about
like
about
like
about
the
of
the
negotiation
design,
is
in
the
determining
compatible
works.
M
Fine,
and
you
can
see
that
by
looking
at
martin's
document
where,
like
the
first
like
like
he
has
like
one
paragraph,
I
have
a
compatible
negotiation
design
works.
Then
a
bunch
of
egg
about
all
works.
I
think
removing
that
would
be
a
pretty
big
mistake,
and
I
do
feel
question
about
that.
I'm
more
than
happy
to
have
both,
as
evidenced
by
the
fact
that
david
and
I
were
to
document
which
has
both.
A
Thank
you,
jonah.
Please,
thanks.
C
Lucas,
I
I
don't
have
a
strong,
so
I
have
an
opinion,
but
I'm
I
don't
I'm
not
going
to
lie
down
I'll,
be
clear,
I'm
going
to
lie
down
on
the
tracks
or
the
roads
for
any
of
this
stuff.
This
is
like
way
too
little
to
light
on
the
road
for,
but
in
terms
of
the
compatible
version,
negotiation
stuff.
I
think
it's
it's
it's
again.
C
I
I
would
like
somebody
to
clarify
to
me
when
I
should
use
compatible
version
negotiation
and
when
I
should
simply
use
transfer,
parameter
extension
mechanisms,
it's
something
that
would
be.
You
know,
maybe
it's
clearer
in
in
david
and
ecker's
heads
and
if
it
is,
then
I
would
appreciate
that
guidance
in
the
draft,
and
I
don't.
C
This
is
again
coming
back
to
the
point
that
I
don't
see
a
difference
between
the
two
in
terms
of
mechanism
and
maybe
I'm
missing
something
subtle
here.
I
don't
think
I
am
because
I
think
we
are
not
creating
any
new
mechanisms.
We
are
using
existing
mechanisms
to
call
something
version
negotiation
there.
That's
how
I
read
it.
C
The
in
terms
of
I
do
want
to
raise
another
point,
and
this
question
has
raised
this
twice
already
and
I
think
it's
important
the
synchronization
points
where
we
can
switch
versions
in
the
compatible
case
are
known
if
they're
new,
I
don't
see
them.
If
they
are
known,
then
they
sort
of
limit
where
you
can
change
the
versions
anyways
and
again
the
question
there
becomes.
What
can
we
accomplish
with
transport
parameters
there
versus
something
like
this?
Something
like
compatible
version
negotiation,
so
the
the
on
the
incompatible
one?
C
C
That's
too,
limiting
the
whole
tcp
doesn't
have
version
negotiation
and
we
suffered
with
that
right
for
a
very
long
time,
and
and
that's
not
something
we
want
to
to
to
relive
being
able
to
do
switch
versions
and
being
able
to
test
them
was
something
that
we've
said
for
a
long
time
we
want
to
do.
We
don't
want
quick,
we
want
to
ossify.
We
want
something
else
also
out
there
and
if
everything
is
happening
under
the
cover
inside
crypto
cover,
then
it's
not
something
that
we're
really
testing
things
happening
on
the
wire.
C
So
incompatible
versions
are
the
ones
that
I
actually
want
to
test.
Those
are
the
ones
that
I
actually
want
to
deploy
to
make
sure
that
we
don't
classify
on
this
version
of
quickview,
and
if
that
means
that
we
change
the
header
format
of
the
quick
packet,
maybe
that's
what
it
is
just
for
fun,
but
that's
that's
a
possibility
too.
A
B
So
no
thanks,
john,
it's
totally
possible
that
I
I
did
a
poor
job
explaining
the
need
for
these
things
in
the
document,
and
actually
I
don't,
I
won't
say
it's
possible
I'd,
say
it's
guaranteed
because
that's
why
we're
all
here,
because
this
document
is
clearly
not
clear
enough
to
convince
everyone
that
it's
amazing
and
also
probably
it's
not
amazing.
B
But
all
things
aside,
I
see
two
reasons
why
there
is
value
in
compatible
version
negotiation
over
extensions,
because
you're
absolutely
right
that
for
many
things
you
could
write
a
quick
extension
that
completely
rewrites
the
short
header
format,
not
the
party
and
variance
I
mean.
What's
inside
the
encryption,
you
could
negotiate
something
and
then
completely
rewrite
the
protocol
after
that.
That
is
a
fact,
but
there
are
kind
of
two
things.
One
thing:
if
you
have
compatible
version
negotiation,
you
can
start
modifying,
let's
say:
handshake
packets,
for
example.
B
The
client
sends
an
initial.
The
server
does
compatible
version
negotiation
to
version
two,
and
then
the
client
sends
his
its
handshake
packets,
as
version
two
and
those
can
have
a
completely
different
format
to
the
one
from
version
one.
So
that
is
one
thing
you
can
do
with
compatible
version
negotiation
that
you
can't
quite
say
you
could
do
it
with
extensions,
but
then
it
becomes
grosser.
B
So
that's
not
a
very
compelling
argument,
but
I
see
this
more
as
an
architectural
long-term
thing,
which
might
be
a
more
compelling
argument,
if
you
say
all
right,
the
evolut
we
we've
come
up
with
this
idea
that
really
completely
rewrites,
how
quick
sure
ford
secure
packets
short
headers
are,
and
it's
great
and
it's
the
world
we
want
to
live
in
going
into
the
future.
B
If
we
do
it
with
extensions,
we
will
be
in
this
world
like
tls,
where
forever
we
are
in
quick
version,
one
with
extension,
called
quick
version,
two
of
extension
called
quick
version
four
and
you
pile
on
things
for
all
eternity,
whereas
if
you
have
conceptually
think
of
it
as
a
new
version,
you
would
say:
okay,
this
is
version
two
for
a
transitional
period.
B
Clients
will
say
I
will
speak
one,
because
there
are
more
servers
that
speak
one
here,
that
today
that
speak
two
and
the
compatible
upgrade
allows
them
to
seamlessly
upgrade
and
then,
as
time
passes,
servers
update
their
code.
You
reach
a
point
where
more
servers
speak
quick,
v2
than
quickv1,
that
you
can
now
start
defaulting
quickv2
and
then
a
little
bit
longer
after
that,
you
can
completely
deprecate
and
remove
the
code
for
quickview
one.
B
So
this
allows
us
to
have
an
ecosystem
that
evolves
as
opposed
to
something
that
is
stuck
piling
on
one
thing
after
the
another
for
all
of
eternity,
and
that's
why
I
think
I
really
want
us
to
go
in
that
direction
because
sure
you
can
make
it
work.
That's
what
we
did
with
tls,
but
being
able
to
have
the
evolvability
of
this
protocol
would
be
really
nice.
A
Thanks
david,
echo
was
in
the
queue.
M
Basically,
if
you
don't
have
like
like
yes,
you
can
always
screw
around
with
extensions
and
transfer
parameters
and
get
what
you
want
but
like
when
that's
the
only
thing
you
can
do
you
get
like
a
giant
like,
as
as
john
says,
a
bucket
of
transport
parameters,
and
that
just
turns
out
to
be
very
difficult
to
manage
in,
like
as
the
protocol
evolves,
and
so
that's
one
of
the
reasons
like
why.
M
What
like,
tlc
one
three
has
a
different
version
numbers,
because
it
just
got
too
too
hard
to
manage,
like
all
the
different,
like
extension
conceptually,
so
I
mean
like
like
yeah,
you
can
always
like
keep
doing
it
like
so
like.
Is
it
like,
and
that's
exactly
what
we'll
do
if,
like
you
know,
if
we
don't
allow
this
to
happen,
but
that's
the
reason
why
I
think
we
should
do
it
because,
like
we'll
be
sad,
I
think
we
set
up.
We
don't
oh
yeah.
C
I
I
do
I
I
appreciate
that
I
think
I
think
so
at
least
it's
clear
to
me
what
we're
talking
about
here
and
that's
what
I
was
trying
to.
I
didn't
mean
to
say
that
it's
a
bad
idea
occur
to
be
clear.
I'm
trying
to
understand
exactly
what
we
get
here
as
against
a
bucket
of
transport
parameters.
I'll
respond
to
one
point
that
david
just
made.
I
think
I
I
I
think
that
being
able
to
do
internal,
like
he
said
like
without
changing
the
first
packets
to
be
version,
one
changing
changing.
C
In
this
particular
matrix
that
we're
building
here,
if
we
have
to
start
with
v1
and
then
switch
to
b2
internally,
well,
we've
already
ossified
b1
right,
so
it
at
that
point
it
doesn't.
We
can
do
a
large
number
of
things
internally
within
v1,
because
we
protected
that
with
crypto,
and
so
we
are
safe
there.
C
But
okay
at
least
understand
this.
I
don't
have
a
strong
opposition
to
compatible.
I
just
think
that
it'd
be
good
for
at
this
point
it
really
becomes
a
question
of
should
we
do
x
with
transport
parameters,
or
should
we
do
it
as
a
version
negotiation
bucket
right
and
that's
a
question
of
taste
to
some
extent
and
maybe
we'll
deal
with
it
when
we
get
there?
C
I
don't
have
strong
opposition
to
trying
to
describe
that,
but
I
think
we'll
have
to
we'll
keep
running
up
against
this
every
time
you're
trying
to
define
a
compatible
version.
Like
somebody
says:
hey,
should
this
be
compatible
version
two
and
I'll
be
like
well?
No,
it's
only
got
two
transport
parameters
and
you
don't
need
it.
C
I
will
challenge
the
one
thing
that
david
just
said,
which
is
I
don't
I
don't
know
this,
and
so
I'm
charging
it
because
mostly
I
don't
know,
and
it's
easy
for
me
to
ask
like
that
and
how
you
explain
it.
I
don't
know
how
you
would
do
this
in
the
middle
of
a
handshake.
B
Oh
well,
you,
the
the
long
header
type,
assuming
you
know
or
whatever
you
like.
If
we're
talking
quick
v1,
this
is
it's
not
an
invariant,
but
you
would
say
that
initials
use
the
first
version
and
the
next
one
use
the
other.
For
example,
or
I
mean
you
would
you
would
use
so
your
main
synchronization
point
is
the
switch
from
long
headers
to
short
headers.
So
during
the
handshake
you.
B
C
Okay,
so
so
I
guess:
okay,
okay,
fair
enough,
so
I
think
in
that
case
you
get
a
little
bit
more
for
doing
so.
The
question
here
then
becomes.
Is
that
that
value
necessary
like
do
we
have
actually
is
that?
Is
there
a
significant
value
in
defining
this
whole?
Like
you
said,
I
think
I'll
repeat
what
you
said,
which
is
this
is
not
the
most
strong.
This
is
not
the
strongest
motivation
here
is
to
be
able
to
change
the
the
handshake
package,
so
I
agree
with
that,
but
yeah,
okay,
that's
that's
helpful.
Thank
you.
B
Actually,
though,
I
wanted
to
respond
to
another
point
of
jonas
really
quickly
about
the
ossification
of
quickview
one,
I
don't
think
we're
there
yet
and
I
think
we
can
still
avoid
it.
So
let
me
give
you
an
example
with
the
big
bad
internet
being
ossified
yeah
like
take
tls
recently
browsers
dropped,
support
for
gs,
1.0
and
1.1.
B
We
managed
to
move
the
echo
system
forward
in
the
presence
of
ossification,
and
I
want
us
to
do
something
similar
with
quick,
where
we
evolve,
quick
from
v1
to
v2,
to
v3
and
and
ideally
we
keep
this
joint
well
oiled,
and
you
know
following
langley's
law
and
make
sure
that
we
have
a
new
one
and
then
once
the
new
one
gets
deployed
enough,
we
aggressively
drop
support
from
the
old
ones.
We'll
have
to
see.
You
know
there
are
many,
because
there
are
there
are
consequences,
but
if.
F
B
Were
able
to
drop
support
for
tls,
1.0
and
1.1,
we
will
be
able
to
drop
support
for
quickview
one
in
favor
of
quick
wii
v2
someday
the
the
big
debate
in
the
or
the
big
question
to
answer
in
the
extension
versus
compatible
version.
Negotiation
is
once
we've
reached
that
day
and
drop
support
for
quick
v1.
A
Thanks
yeah
there's
we
have
20
minutes
left
I'd
like
to
hear
from
ryan
he's
been
in
the
queue
for
a
while
and
then
mike
kocheb
matt
wanted
to
say
a
few
words
which
I
think
is
going
to
give
a
you
know,
kind
of
a
round
up
of
the
the
chess
perspective
here,
see
some
people
popping
up
after
that,
and
I
think
we'll
have
time
for
them.
Just
as
a
comment
from
myself.
A
I'd
love
to
run
a
poll
just
so
I
could
get
a
view
of
how
the
people
on
this
call
feel
about
compatible
and
incompatible,
because
sometimes
people
are
breaking
up
and
I'm
maybe
not
getting
the
right
view.
I'm
not
allowed
to
run
the
poll
from
the
with
the
web
app.
So
that's
annoying,
but
it's
not
a
boat
anyway.
So
I
I
would
like
to
find
a
way
to
gain
a
sense
of
the
feeling
whether
that's
taken
to
the
mailing
list.
C
A
A
I'm
seeing
all
kinds
of
stuff
here,
let
let
me
have
a
think
while
matt
matt
says.
H
Okay
yeah,
so
my
my
thing
was
that
so
my
my
reading
of
the
discussion
so
far
is
that.
H
Several
people
are
passionate
about
there
being
incompatible
version
negotiation
and
that
being
required.
A
few
people
have
made
the
argument
that
maybe
it
is
not
required
but
doesn't
seem
to
be.
You
know
no
one's
like
it
must
not
be
there
right,
compatible
version.
Negotiation
seems
like
we
think
that
it.
You
know
it
probably
has
a
reason
to
exist,
but
it's
not
clear
this
not
clear
when
you
would
use
it
exactly
I'll.
H
Also
note,
though,
we
have
a
draft
that
has
both
of
these
things
in
it,
and
I
have
not
heard
anyone
say
that
they
have
particular
issues
with
the
draft
as
it
currently
is.
So
it
sounds
to
me
like
we
have
people
that
think
both
of
these
kinds
of
version
negotiation
should
probably
exist,
and
we
don't
really
have
anyone
that
really
thinks
that
one
should
definitely
not
exist
and
we
have
people
willing
to
design
or
continue
to
design
the
system
which
supports
both.
H
So
I,
the
question
I'd
like
to
pose
is:
is
anyone
really
opposed
to
going
forward
and
with
the
current
drafts
that
david
and
ecker
have-
or
you
know
they
can
change?
Obviously,
but
like
is
there
anything?
Fundamentally,
that
we
think
is
not
there
and
that
we
really
don't
want
to
have
both
of
these
things
in
a
version,
negotiation.
H
And
yes,
martin
this:
this
is
why
not
both
basically
is
there
any?
Is
there
a
compelling
reason,
besides
purity
and
oh
well,
in
practice,
we
probably
won't
need
both?
Is
there
any
reason?
Is
there
any
disadvantage?
Someone
can
come
up
with
for
having
both
other
than
it's
mildly,
more
annoying
to
implement,
and
maybe
I
don't
know
how,
when
to
use
compatible
version,
negotiation
versus
just
piling
on
extensions.
H
N
Yeah,
I
mean
it's
not
an
answer
to
your
question.
I
I
just
wanted
to
make
a
comment
in
support
of
compatible
negotiation
and
why
we
should
do
it
now.
Is
this
the
right
time
for
that.
N
So
I
take,
I
take
a
backseat
to
no
one
in
sweating,
the
ossification
of
the
of
the
long
header
version
field.
I
think
my
track
record
on
that
is
pretty
long.
N
If
the
war
should
happen
and
we
do
ossify
on
those
four
bytes
being
won
at
some
point,
then
we're
going
to
need
to
do
a
tls
thing
and
have
a
back
channel
transport
parametery
thing
which
is
compatible
negotiation,
and
so
I
think
it
would
be
unfortunate
if
we
just
did
incompatible
and
and
then
like
found
that
ossified
and
then
had
to
back
in,
like
the
compatible
thing
and
try
to
like.
Have
all
these
hosts
or
something
we're
doing
one
type
of
version
negotiation.
One
of
them
are
doing
another.
H
I
see
some,
you
know
people
saying
that
both
or
all
three
is
good.
It
sounds
like
miria,
she
doesn't
know
when
we
should
use
compatible
versions
and
I
think
that's
a
that's
a
legitimate
question.
That's
a
lot
of
what
jonah
is
saying
too,
which
is
that
it's
not
really
entirely
clear.
What's
the
semantic
difference
between
a
compatible
version
and
just
using
transport
parameters
and
extensions-
and
I
think
that's
a
legitimate
question,
but
it's
almost
sort
of
is
to
me
anyway.
H
It
seems
sort
of
aside
from
the
mechanism,
and
so
we
kind
of
want
to
make
forward
progress
on
the
mechanism
right
now
and
it
sounds.
It
doesn't
sound
to
me
unless
anyone
can
yeah
and
we
probably
should
have
guidance
in
the
draft
about
you
know
when
to
use
compatible
versions
because,
as
ecker
said,
the
mechanism
for
compatible
version
negotiation
is
really
simple.
So,
but
I
think
we
are
probably
approaching
a
place
where
there's
it
sounds
like
there's
kind
of
roughish
consensus
that
this
draft
can
go
forward
and
we
can
add
more
stuff
to
it.
H
E
Thank
you,
so
I
think
I
might
have
said
this
earlier,
but
I'm
not
really
sure
if
the
current
design
of
compatible
version
upgrade
really
meets
the
requirement
easily
enough
to
reduce
one
round
trip
and
that's
because
it
only
carries
the
version
number
I
mean.
Typically,
a
transport
has
properties
being
associated
to
the
version,
so
we
need
to
transfer
those
alongside
the
version,
but
it
doesn't
really
provide
that
opportunity.
E
E
Then
you
know
we
have
to
transmit
the
first
flight
of
the
alternate
handshake
transcript
in
the
parameters,
but
you
know
the
current
mechanism
doesn't
define
that
kind
of
way
I
mean
so.
My
point
is
that
I'm
not
entirely
sure
if
we'd
be
very
happy
with
the
current
design,
when
we
designed
v2
or
compatible
version
play.
That's
one
of
the
reasons.
I
think
we
should
better
plan
the
design
of
compatible
version
upgrade
to
when
it
becomes.
H
F
To
to
elaborate,
on
my
point
a
little
bit,
so
what
makes
me
nervous
is
that
we
don't
have
a
good
understanding.
Our
safe
self-water
compatible
version
is
right
and
like
if
we
don't
understand
that,
then
we
get
easily
in
the
situation
where
people
just
randomly
design
a
new
version
instead
of
using
transfer
parameters
or
whatever.
H
B
Indeed,
I
just
want
to
push
back
on
the
idea
that
if
someone
doesn't
fully
understand
this,
we
should
therefore
not
do
it.
I
think
that
this
isn't
as
misunderstood.
I
think
the
concept
is
fairly
simple.
Compatible
means
that
you
can
take
a
first
flight
and
convert
it.
B
I
do
agree
that
we
should
provide
more
guidance
text
to
the
document
in
order
to
make
sure
that
nude
or
designers
of
new
versions,
don't
accidentally
shoot
themselves
in
the
foot,
but
I
do
not
see
this
as
a
foot
gun
compared
to
all
the
things
you
can
do
wrong
when
designing
a
new
protocol.
So
I'm
really
not
worried
here.
I
don't
think
there
is
like
much
of
a
risk.
This
problem
seems
to
be
decently
well
understood,
and
we
even
have
some
examples
of
you
know
the
compatible
negotiation
between
draft
versions.
B
If
we
wanted
to
I'm
not
particularly
concerned
here.
H
So,
okay,
so
it
sounds
to
me
like
lucas,
is
in
in
the
queue,
but
it
sounds
to
me
like
both
ecker
and
david
recognize
the
compatible
versions
being
vague
as
a
problem
and
are
willing
to
add
text
to
that
effect.
H
So
it
sounds
like
that's
probably
the
biggest
thing
that
we
should
take
away
from
this,
and
also
because
I
think
incompatible,
it
sounds
like
people
agree
should
probably
exist,
but
that
would
be
a
good
thing
forward
for
david
and
ecker,
I
think,
is
working
on
pr's
too,
and
then
people
that
have
concerns
about
it
like
miria
and
janna.
Reviewing
those
pr's
would
be
very
useful.
Lucas.
H
A
Okay,
cool
yeah,
so
I
clicked
a
button
and
it
booted
me
out
with
the
web
app
and
into
into
the
desktop
app
well.
I
can
actually
see
everyone
now,
so
I
understand
what
john
was
talking
about
earlier.
Unfortunately,
I
did
miss
some
of
the
discussion
in
that
process,
because
matt
was
coming
out
of
a
playstation
5
controller,
very
odd,
we're
very
we're
pretty
short
of
time,
but
I
don't
wanna,
I
don't
wanna
chew
up
too
much
stuff.
I
think
matt's
probably
covered
a
lot
of
good
stuff.
A
There
he's
got
a
good
handle
on
this
to
me
that
the
thing
that
does
stand
out
is
like
these
design
questions
versus
like
actually
just
good
improvements
to
the
document.
Just
like
you
mentioned
about
guidelines
or
recommendations
or
deciding.
Maybe
maybe
some
other
document
could
could
help
people
and
that
we're
not
we're
not
able,
as
a
working
group,
to
make
progress
on
any
of
that,
because
we're
stuck
on
on
these
questions
that
we've
got
we've
we've
all
expressed
a
lot
of
views.
So
far.
A
I
did
like
the
suggestion
of
taking
a
show
of
hands
for
the
different
options,
purely
as
like
an
illustrative
view
of
this
that
we
can
then
capture
somewhere,
and
you
know
continue
that
discussion
elsewhere,
put
it
into
the
minutes,
etc.
So
I
would
like
to
trial
that
while
we've
got
eight
minutes
to
do
so,
so
the
instruction
here
would
be
to
use
the
raise
hand
button.
A
When
you
support
one
of
the
options
I
will
present
and
yes,
john,
is
suggesting
doing
a
trial
question
so
I'll
do
the
classic.
Do
you
like
chocolate,
ice
cream.
A
I
see
a
bunch
of
hands,
there's
some
thumbs
up
the
thumbs
up,
aren't
so
great
because
they
disappear,
so
any
emoji
reactions
are
harder.
What
I
I
would
do
like,
as
the
suggestion
says,
is
to
take
screenshots,
then
I
can
go
away
and
count
those
things
and
just
get
a
few.
So
yes
and
you
can.
A
Oh,
that's
thank
you,
mine,
cool
yeah
and
actually
it
sorts
them.
So
that's
a
lot
easier.
Okay,
that's
that's
great
yeah
david
suggested.
Maybe
a
preference
in
the
chat.
I
honestly
don't
know
him,
but
for
short
time,
let's
go
with
the
show
hands
up
to
start
with.
So
yes,
the
first
question
it
will
be.
Do
people
believe
that
compatible
vision?
Negotiation
is
a
requirement.
A
A
A
Okay,
thank
you
for
that,
and
now
I'll
ask
a
different
question.
So
if
you
want
to
lower
your
hands
just
just
to
avoid
any
doubt
here,.
A
A
M
A
A
A
Yeah,
let's
do
it,
we've
got
a
few
minutes.
Okay,
this
is
so
fun
we'll
do
it
in
the
same
order.
Please
raise
your
hand
if
you
for
compatible.
A
B
Should
we
ask
like
so
chris
wood
had
his
hand,
could,
should
we
ask
him
if
this
was
intentional
and
something
we
should.
N
A
A
So
I
say
this
is
okay.
Yes,
please
raise
your
hand
if
you
believe
that
incompatible
version
negotiation
is
not
a.
A
And
I
don't
see
any
hands
there.
Okay,
thank
you.
Thank
you
for
just
finding
patience
with
that
one.
Yes,
we
have
three
minutes
matt.
Is
there
anything
you'd
like
to
pick
up
here.
H
I
would
just
reiterate:
it
sounds
like
maybe
ecker
and
david
can
confirm,
but
it
sounds
like
they'd
be
willing
to
incorporate
some
of
this
feedback.
It
doesn't
sound
like
anyone
else
is
willing
to
come
up
with
any
other
drafts.
Is
that
right?
If
not,
if
you
are
really
really
willing
to
come
up
with
a
totally
alternate
design,
please
get
in
the
queue
now,
but
it
sounds
like
we
have.
You
know,
willing
participants
in
the
current
draft
and
so
and
we
have
feedback
on
that
at
least
meta
feedback.
M
We're
having
to
make
the
changes
that
were
indicated
in
the
discussion-
and
I
understand
martin-
has
some
suggestions
about
spelling
this
differently
and
we're
interested
in
during
his
sessions
in
more
detail.
B
And
to
reiterate
what
ecker
said?
Yes,
we're
absolutely
happy
to
take
this
feedback.
Please
make
sure
to
take
your
like:
send
your
feedback
to
the
list
or
to
github
issues.
If
you
haven't
already
so
we
don't
miss
it.
A
Yeah
and-
and
just
with
that
final
minute,
I'd
like
to
thank
everyone
for
attending
today
and
putting
some
effort
in
and
having
some
good
conversation.
It's
it
wasn't
an
easy
subject
for
this
one,
and
I
I
feel
that
we've
made
some
progress.
We
can
confirm
that
on
the
list-
and
I
you
know,
I
do
look
forward
to
contributions
and
progress
being
made
on
the
drafts,
and
you
know
maybe,
when
we
get
around
to
the
next
itf
meeting,
we
can
get
back
into
the
the
issue.