►
From YouTube: IETF114-HTTPBIS-20220728-1730
Description
HTTPBIS meeting session at IETF114
2022/07/28 1730
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
That's
fine!
By
the
way,
I
don't
really
care
that
microphone
on
the
pink
x,
because
the
camera
will
look
at
you,
yeah
yep
I'll
call
you
up
yeah
every
yeah
exactly
and
the
cue
for
that
is
using
the
little
phone
thing
to
put
your
raise
your
hand
in
that,
and
then
you
get
in
that
my
client.
So
questions
come
from
that
mic
and
the
presenters
have
this
mic.
A
A
A
E
E
F
B
H
A
All
righty,
we
do
have
a
tight
agenda,
so
let's
get
started.
Welcome
to
the
meeting
of
http
at
ietf114.
I
think
this
is
the
first
in
semi-in-person
meeting
at
an
actual
ietf
meeting.
We've
had
it
in
a
while.
Thank
you,
everyone
for
all
of
your
attendance
of
the
various
virtual
interims
we've
had.
We've
made
a
lot
of
great
progress,
but
it's
also
good
to
see
faces
here
and
on
medeco,
and
hopefully
we
continue
to
make
good
progress
today.
A
Also
in
itf
we
have
codes
of
conduct
and
general
rules
of
trying
to
be
civil
and
friendly
to
each
other,
and
this
is
a
great
group
at
doing
that.
So
you
know,
as
we
are
going
through
our
work
today
and
hearing
about
some
new
work,
let's
make
sure
that
we
are
welcoming
to
it
and
give
good
constructive
feedback
and
then
also
for
the
people
who
are
on
site
masks
are
required.
You
do
need
a
kn95,
equivalent
dot
dot
mask.
E
A
Absolutely
yeah,
thank
you
all
right,
so
here's
our
agenda
for
today
we
are
currently
in
the
administrivia.
We
have
several
active
drafts
that
we
are
going
to
get
a
catch
up
on
along
with
a
summary
of
a
side
meeting
that
occurred
earlier
this
week,
and
then
we
have
four
newer
proposals
that
are
not
things
that
we
have
adopted
into
this
working
group,
but
have
been
discussed
on
list.
A
A
A
I
Basically
alt-service
is
great
for
being
able
to
narrowly
tailor
information
to
one
particular
class
of
users,
but
a
lot
of
what
we're
using
it
for
right
now
is
really
about
protocol
capabilities.
Do
I
support
h3?
Do
I
support
h2?
Do
I
have
multiple
endpoints
and
all
of
that
can
go
in
the
dns
and
service
b.
The
https
record
does
a
great
job
for
that.
We
should
just
use
it
and
the
main
thing
that
the
server
knows
when
you're
talking
to
it
is
if
it
is
not
the
right
place
for
you
to
be
talking.
I
I
So
what
we're
really
trying
to
cover
is
the
case
where
the
server
thinks
it's
probably
not
the
best
endpoint
for
you
to
be
using,
but
it's
willing
to
continue
serving
your
requests.
If
you
need
it
to,
we
want
some
degree
of
stickiness
there.
We
want
that
recommendation
to
last
until
the
network
changes
or
the
server
config
changes
now
part
of
the
problem
we
have
with
alt
service
today
is
the
client
only
kind
of
knows
when
the
network
changes
and
the
client
does
not
know
when
the
server
changes.
I
I
I
I
I
Do
we
build
something
entirely
new
and
adopt
a
draft
there,
or
do
we
try
and
shove
it
into
alt
service
as
it
currently
exists,
we
could.
We
could
hijack
an
aopn
value
to
serve
as
a
sentinel,
something
like
use.
This
one
equals
the
hostname
we
care
about,
or
we
could
be
really
crazy
and
just
drop
a
host
name
in
the
alt
service
field.
I
I
C
David
skanazi
is
she
beheader
enthusiast.
I
apologize
for
missing
this
side
meeting.
It
happened
to
conflict
with
sleep,
and
the
sleep
working
group
had
to
be
prioritized.
Sorry
about
that.
The
it
seems
like
what
this
is
saying
is
that
the
use
of
quick
is
dependent
on
the
https
frame.
Now.
Is
that
a
correct
understanding,
sorry
on
the
https
resource
record
in
the
dns.
C
C
I
couldn't
do
this
for
chrome,
because,
while
we're
trying
to
move
all
deployments
of
chrome
to
use
the
chrome's
custom,
dns
client,
which
does
everything
itself-
that
one
knows
how
to
query
for
those
records
because
we're
also
on
top
of
things,
but
we
can't
use
that
on
all
os's,
especially
when
there
are
oss
where
things
are
complicated.
Like
there's
a
vpn.
C
Okay
screw
it.
This
is
too
hard.
We
fall
back
to
get
our
info
and
then
we
would
lose
quick,
so
that
would
be
a
non-starter
for
us.
I
would
say
I
would
love
to
be
part
of
this
discussion
because
I
think
that's
that's
an
important
feature
for
us,
even
though
I
love
the
idea
of
putting
everything
in
the
dns
here
I
don't
think
short
term.
It's
necessarily
the
right
plan.
I
I
think
that's
a
really
good
point
about
compatibility
in
the
short
term.
I
think
that
almost
sounds
like
an
argument
for
being
able
to
shoehorn
it
into
the
existing
old
service,
such
that
you
could
just
say,
I'm
going
to
also
include
some
legacy,
alt-service
entries
and
I
accept
the
problems
if
I
have
to
use
one
of
those.
But
if
I'm
on
a
platform
where
I
can't
query
service
b
yeah,
that's
what
I
got
to
do
that.
K
I
A
C
David's
kanaz
another
option
would
be
to
do
the
working
group
last
call.
I
think
that
would
be
useful
because
it
would
get
everyone
to
read
it
and
then
park
it
there
don't
send
it
to
the
iesg.
I
mean
that
tells
us
that,
barring
any
major
news
that
come
about
service,
this
will
go
forward,
but
it's
not
open
season.
Like
the
working
last
already
happened.
This
is
pretty
much
done.
L
B
M
A
J
J
As
for
the
current
issue
status,
we
have
four
open
issues.
I've
split
these
into
two
parts
currently
in
scope
is
a
issue
2185
named
cookie
octet
reality
check
the
the
one
sentence
summary
of
this
is
that
the
specs
current
structure
is
confusing
and
prone
to
incorrect
implementation,
specifically
around
uas
that
are
accidentally
implementing
the
more
strict
server
syntax
rather
than
the
more
permissive
ua
requirements.
J
A
little
while
ago,
the
spec
was
updated,
such
that
same
site
needed
to
take
into
account
redirect
change
chains
with
every
site
in
the
chain
needing
to
be
same
site.
Both
chrome
and
firefox
attempt
attempted
to
implement
this
and
saw
a
ton
of
sites
break,
so
we've
backed
it
out
and
now
we're
trying
to
figure
out
what
to
do
with
it
under
the
maybe
should
defer
these.
This
is
my
opinion.
J
J
J
Finally,
there's
about
14
additional
deferred
issues
that
are
not
in
scope.
Four,
six,
two,
six
five
abyss
any
longer
coming
back
to
the
in
scope
issues.
I
just
want
to
talk
a
little
bit
more
about
those
two
one.
Eight
five.
One
of
the
proposed
changes
for
this
issue
is
to
merge
the
ua
and
server
syntax,
that
is
to
say,
allow
servers
to
create
cookies
that
adhere
to
the
more
permissive
ua
requirements
rather
than
their
existing
more
strict
requirements.
J
If
the
consensus
is
the
former
merging
the
syntaxes,
then
I
suggest
that
this
issue
be
deferred
because
that's
a
very
significant
redesign
of
the
spec.
If
the
consensus
is
the
latter,
the
rephrasing,
then
I
think
that's
probably
in
scope
for
six
two
six
five
bis
and
then
for
two
104.
The
redirect
we're
currently
considering
this
a
blocking
issue
for
six
two,
six
five
best.
G
G
O
J
A
P
J
So
what
I
meant
by
work
was
not
so
much
changing
the
the
spec
itself.
It's
more
that
it
has
the
potential
for
a
lot
of
side
effects
that
we
would
need
time
to
sit
and
see
how
that
actually
planned
out
rather
than
going
ahead
and
moving
into
into
last
call.
I'd
really
feel
better
if
we
did
that
that
the
spec
had
time
to
sort
of
like
wait
and
see
for
servers
to
actually
implement
this
new
syntax
and
what
the
results
could
be.
E
B
Okay,
I'm
I'm
a
little
confused,
then,
because
the
proposal
that
I
made
full
transparency
was
to
use
the
arbs
text
construct
from
http
core,
which
does
exactly
what's
you
know,
being
talked
about
here.
It
effectively
obsoletes
a
particular
range
of
characters,
so
that
I
don't
think
it
would
have
any
impact
on
implementations.
B
J
Yeah,
I
I
did
see
your
change
mark
and
I'm
happy
to
talk
more
offline.
My
big
concern
there
was
we've
had
evidence
in
the
past
of
implementers
just
kind
of
skimming
the
spec
and
implementing
whatever
looked
right,
and
I'm
not
100,
confident
that
they
would
understand
or
yeah
they
wouldn't
understand
what
the
obsolete
is,
they'd,
see
a
grammar
and
they
would
implement
it.
B
E
A
B
So
you
know
seconds
since
the
epoch
which
most
people
have
trouble
reading.
I
see
both
sides
of
this
argument.
I
think
that
that
if
I
can
try
and
characterize
them,
you
know
if
having
a
human
friendly
presentation
is
better
for,
for
developers
doing
debugging
it's
easier
to
make
sure
that
it's
presented
correctly
in
tools,
whereas
a
a
integer
representation
is
at
least
in
the
textual
form,
easier
to
parse
and
less
overhead
to
parse.
B
Is
a
nice
thing
to
do
what
I
think
it
comes
down
to
is
that
if
you
have
tools
presenting
your
your
your
messages
and
they
understand
that
a
particular
header
has
a
particular
type,
then
it
doesn't
matter
whether
we
have
a
special
type
or
not.
They
can
say.
Oh
look,
I
know
this
is
expires.
I
know
that
that's
a
date
look
there's
an
integer,
but
I'll
show
the
user
a
human
friendly
date
to
be
to
be
nice
about
it.
B
The
problem
is,
is
that
if
they
don't
recognize
that
it's
a
date,
then
you
can
see
the
integer,
whereas
if
we
have
a
date
type,
then
it
can
be
automatic,
you
can
have
a
tool
that
does
the
right
thing
and
it's
hidden
from
the
user,
and
it
happens
for
all
dates,
not
just
the
ones
that
it
happens
to
know
about.
I
think
that's
what
it
comes
down
to.
There
are
some
you
know,
concerns
about.
B
If
we
don't
ever
have
a
binary
structure
types
which,
of
course
we
don't,
you
know
we
have
don't,
have
anything
adopted
yet
there
and
we
don't
have
any
market
adoption
there.
Yet,
of
course,
then
we're
stuck
with
the
textual
representation,
which
does
have
a
little
bit
more
overhead
parsing.
That
does
have
a
little
bit
more
overhead
on
the
wire.
I
think
it's
you
know.
B
We
just
used
the
iso
format,
but
I
think
we
do
need
to
make
a
decision,
because
this
is
our
one
opportunity
to
get
it
used
for
if
we,
if
we
do
have
a
date
type
to
get
it
used.
For
you
know
the
headers
we're
covering
here
there's
also
a
discussion
in
http
api
about
headers
that
they're
minting
that
might
have
dates
in
them,
and
you
know.
B
B
G
That's
how
you
tell
so.
I
tend
to
think
that
the
machine,
readable
thing
is
probably
where
I
would
head
the
integer,
not
just
because
I
like
the
ease
of
processing
of
that
that
sort
of
thing,
but
because
even
the
dates
aren't
particularly
helpful
in
a
lot
of
cases.
Anyway,
I
have
to
deal
with
time,
zone
changes
and
all
that
sort
of
thing,
often
than
it.
It
takes
me
10
minutes
to
work
out,
work
that
out
and
the
tools
the
tools
are
better
at
that
sort
of
thing
anyway.
G
B
A
B
A
D
Yeah,
I
don't
have
strong
feelings
about
this,
but
I
do
think
that
it
is
more
developer
friendly
to
have
a
string
based
representation
that
is
vaguely
human
readable.
Yes,
I
understand
that
not
everybody
especially
me
calculations
and
things
like
that,
but
it
is
much
easier
to
say,
compare
two
values.
At
least
you
know
speaking
anecdotally
that
are
date
strings,
as
opposed
to
two
very
large
integers
trying
to
figure
out
what
the
difference
is
between
those
two
again
as
a
human
and
as
a
developer.
E
N
Q
I
E
B
B
That
is
the
integer
which
it
has
those
nice
properties,
but
it
gives
a
when
you,
when
you
convert
it
to
something
that
you
need
to
show
to
humans
or
in
wireshark
or
whatever.
Then
you
get
the
nice
human
readable
properties,
which
you
know
what
I'm
getting
from
the
people
who
are
kind
of
using
http
rather
than
implementing
http.
G
H
Eric
near
apple,
I
would
say
that
we
provide
some
tools
and
there
are
a
lot
of
other
tools
that
we
don't
provide,
but
at
least
in
many
of
the
tools
that
the
apple
ecosystem
uses
have
lots
of
places.
Where
there's
something
that
is
ugly.
And
I
say
that
with
quotes
in
for
humans,
but
makes
a
lot
of
sense
for
a
wire
format
and
we're
pretty
used
to
saying
hey.
Nobody
wants
to
look
at
this
massive
integer
and
try
to
determine,
if
that's
yesterday
or
three
years
ago.
A
Okay,
I
mean
it
does
sound
like
no
one
would,
you
know
not
be
able
to
handle
either
case
like
it
seems
like
there's
no
blocking
opinions
in
either
direction.
I
guess
if
there
is
a
blocking
opinion,
I
have
a
direction,
please
speak
up
now,
but
they
all
seem
to
be
preferences
for
what
is
easier
and
so
and
different
people
have
different
perspectives
on
what
is
convenient
for
them.
G
E
A
N
D
D
So
I'm
not
going
to
go
into
depth
on
how
this
all
works,
because
we've
presented
this
a
bunch
of
times,
but
basically
it's
a
detached
signature
mechanism
for
http
messages
designed
to
work
across
http
versions
and
in
all
of
sort
of
the
weird
kind
of
chopped
up
ways
that
http
kind
of
exists
out
in
out
in
the
wild,
and
this
is
for
applications
that
really
can't
rely
on
whole
message.
Encapsulation,
like
you,
would
get
with
something
like
ohio
or
or
anything
like
that.
D
And
then
that
gives
you
your
signature
output,
which
consists
of
both
the
list
of
things
that
got
signed
and
the
signature
itself.
You
send
both
of
those
as
message
headers,
and
that
is
how
you
get
a
signed
message
now,
the
message
component.
We
had
to
invent
a
bunch
of
terminology
for
this
and
I'm
going
to
be
using
that
throughout
throughout
the
presentation.
D
D
D
So
what
have
we
been
up
to
we've
added
a
few
more
security
and
privacy
considerations?
How
to
deal
with
weird
stuff
like
set
cooking,
which
doesn't
behave
like
other
http
fields?
We've
clarified
how
this
relates
to
the
digest
draft,
which
we'll
be
hearing
about
I
think
later
today,
and
we
mostly
most
of
what
we
did
was
just
a
lot
of
cleanup
clarifying
those
terms
that
I
was
just
using
making
sure
we're
using
the
right
terms
throughout
we
expanded
our
examples.
D
D
D
Of
this
out
in
the
wild,
we
also
added
the
byte
sequence
flag,
mostly
to
deal
with
problematic
fields
like
set
cookie,
which
don't
follow
the
list
syntax
and
could
be
used
to
leverage
some
very
esoteric
but
still
possible
attacks
against
this.
So
when
you're
doing
things
like
set
cookie,
you
binary
encode
it
basically
and
then
and
then
wrap
that
into
your
signature.
That
way,
this
has
been
being
implemented
all
over
the
place.
D
D
So
this
is
the
canap
smurf
for
those
that
don't
know,
and
so
that
is
a
direct
reference
to
to
this
work,
you
know
in
full
disclosure.
I'm
also
lead
editor
of
the
canap
specification
in
that
working
group,
but
there's
it's
not
a
coincidence
that
these
two
things
fit
together.
Well,
an
interesting
one
that
I'm
not
directly
involved
in,
but
the
financial
grade,
api
draft
specification
and
open
id
foundation
is
also
referencing.
This
using
message
signatures
specifically
for
data
non-retaliation
for
api
calls.
D
This
is
not
token
binding.
Specifically,
it
is
in
fact
the
api
is
signing
a
response
that
says
no
really.
This
is
this
is
the
response
to
that
particular
request
and
you
can
prove
it
based
on
this
signature.
So
a
really
interesting
use
case
a
bit
outside
of
what
brought
me
into
trying
to
define
this
stuff,
but
there
we
go,
hbsig.org
is
still
up
and
running.
It's
been
updated
a
little
bit.
You
know
please
go
feel
free
to
play
around
with
that.
D
I
actually
generated
the
example
at
the
beginning
of
this
presentation
using
httpsig.org,
so
the
the
tooling
in
there
is
pretty
fun
and
the
python
library
that
runs
the
actual
parsing
and
crypto
stuff
is
the
sorry
I'll
answer
the
chat
question
in
a
moment,
the
python
library
that
runs
this
is
actually
now
published
on
pi
pi,
so
you
can
pull
down.
I
think
it's
http
sig
pi
is
what
I
had
to
name
it,
and
you
can
pull
that
down.
D
D
So
at
this
point
the
authors
believe
that
we're
we
think
we're
actually
pretty
ready
for
working
group
last
call
the
core
has
been
stable
for
a
very
long
time.
The
stuff
that
we've
added
recently
has
been
mostly
like,
refinements
and
corner
cases,
and
a
lot
of
editorial
stuff
we're
seeing
more
and
more
implementations
we're
seeing
implementations
that
interrupt
with
each
other.
D
Other
work
is
depending
on
this
and
there's
only
a
handful
of
issues
that
we
think
that
that
are
in
the
issue
tracker
today,
that
we
think
we
can
close
pretty
quickly
either
without
action.
Just
before
working
group
last
call
if
we
can
get
some
good
feedback
or
as
part
of
working
on
last
call,
I
was
going
to
go
through
that
handful
of
issues
really
quick
here.
N
D
R
D
D
Please
go
read
through
that.
Editors
are
currently
leaning
towards
what
we
have
in
that
pr.
As
the
resolution
to
this
issue,
2134
we're
not
exactly
sure
what
to
do
with
cash.
If
we
need
more
text
in
there
there's
some
weird
states
things
can
get
into
if
you're
getting
a
a
signed
responses
from
a
cache
like
is
that
as
meaningful?
If
you're
responding
to
a
signed
request
with
a
cast
response,
you
know:
are
there
gotchas
there
that
that
we
should
be
aware
of?
We
have
some
text
in
there.
D
We
don't
know
if
it's
good
enough.
We
are
not
the
experts
to
this.
So
please
help
us
out
with
that.
Even
if
it's
saying
hey,
I
read
through
things,
and
it
looks
okay
and
then
finally
lucas
raised
the
issue
of
server
push.
We
think
that
our
the
way
that
we're
defining
message,
context
for
deriving
all
of
the
content
is
clear
enough
that
server
push
messages
in
htmh3
should
should
still
be
fine,
but
we
just
don't
know.
D
You
know
we'd
like
to
get
other
people
to
take
a
look
at
this.
So
we
think
that
these
last
two
like
might
need
a
little
bit
of
text.
Might
not
we
just
actually
don't
know
and
that's
all
I've
got
like.
I
said.
We
think
that
this
is
in
pretty
good
shape
and
ready
for
hopefully
ready
for
working
group
last
fall.
C
O
C
Sorry
is
super
hard
doesn't
look
like
it
actually
is,
but
the
number
of
security
vulnerabilities
we've
seen
in
that
space
is
astounding,
request
smuggling
blah
blah
yadda
yadda
in
this
proposal,
we're
signing
a
normalized
version
and
sending
a
non-normalized
version,
which
sounds
like
a
recipe
for
a
time
of
check
to
time
of
use
problem.
So
what
am
I
missing?
Something.
D
Yes,
for
the
most
part,
you're
assigning
the
header
value
exactly
as
it
as
it
is
sent
across
the
wire.
The
the
field
value
is
sent
exactly
across
the
wire.
There
are
cases
where
you
can
opt
into
transforming
that
in
specific
ways.
So
there's
one
where
it
says:
use
the
strict
structured
field,
serialization
definition.
C
D
D
S
Basically,
so
I
think
the
optional
is
is
fine
because
it
is
effectively
equivalent
to
this
to
just
having
it
mandatory,
but
somebody
could
put
null
in
or
nil
or
whatever
you
want
to
use,
but
I
would
say
that
it's
better
to
say
mandatory
or
output
nil,
because
then
at
least
you
can
be
sure
that
all
the
libraries
will
implement
it,
because
if
some
libraries
don't
implement
it,
then
it's
not
gonna
work.
No
one
will
be
able
to
use
it,
so
I
prefer
mandatory.
D
Okay,
no
none
of
the
libraries
that
I've
seen
are
that
strict
about
the
parameters
and
it's
an
extensible
field
set
to
begin
with
so
point
taken.
But
what
we've
tried
to
do?
If
you
look
at
the
pr,
what
we've
tried
to
do
is
instead
say
that
if
a
specific
application
requires
it,
then
then
that
needs
to
be
enumerated
as
part
of
the
application
of
signatures.
E
R
T
U
My
audible,
it
sounds
like
I'm
cool,
hi
yeah,
so
I
guess
first,
I
want
to
echo
what
david
said
about
the
normalization
thing
like
we've
seen
in,
like
basically
every
cryptographic
thing
that
uses
signatures
like
whenever
you
have
this
complex
normalization
process.
Then
there's
like
there's
a
lot
of
room
for
like
if
there's
any
property
of
the
message
that
the
normalization
process
drops
which
like
by
construction,
it
kind
of
does.
U
If
that
thing
is
ever
read
by
any
code
downstream
that
that
is
a
place
for
an
attacker
to
like
change
the
interpretation
of
the
message
more
than
what
you're
intended
to
like.
Even
the
ops
folding
thing.
If
the
downstream
code
used
an
api
that
was
like
sensitive
to
where
the
headers
were
split,
which,
like
you
know
they
like
morally
shouldn't,
but
http
is
a
complicated
format
like
that
will
result
in
a
security
vulnerability.
U
I
can
kind
of
understand
why
you
sort
of
went
in
this
direction,
because
you
want
to
sign
a
thing
that
got
exploded
into
the
like
http
serialization
and
so
maybe
for
some
use
cases
they're
kind
of
forced
into
this,
not
secure
mode,
but
for
a
lot
of
other
kids
but
like
where
you
can
get
away
with
it.
It's
much
safer
to
have
the
thing
you
parse
be
exactly
the
thing
you
sign
so,
for
instance,
maybe
like
take
your
message
and
encode
it
in
this,
like
binary,
http
format
and
then
sign
just
that.
U
That
was
what
we
did
like
early
on.
When
I
I
helped
the
sound
exchange
folks
design
like
some
of
their
formats,
and
that
was
one
thing
that
we
were
trying
to
push
for
that,
like
the
thing
that
you
signed
is
the
thing
that
you
parse
and
that
way,
there's
no
room
for,
like
other
unsigned
input
to
get
in,
and
it's
sort
of
related
to
where
attackers
can
inject
stuff.
U
So
I
noticed
you
mentioned
that
there
was
a
lot
of
like
signature
parameters
that
can
change
how
the
signature
like
it
looks
like
it
impacts
both
the
normalization
process
and
just
changes.
What
is
even
signed
is
that,
like
just
carried
in
a
header
that
the
sender
just
like
fills
in,
however,
they
like
or.
U
U
R
U
A
U
R
Main
worries
are
particular,
if
you
could
point
out
where
you
are
seeing.
You
know
significant
normalization
of
of
component
content.
You
know
component
values
that
would
be
appreciated
because
the
as
a
spec
author,
one
of
the
things
we've
we've
tried
to
avoid,
is
any
normalization
of
values
beyond
what
is
already
just
inherently
part
of
http,
such
as
collapsing
of
multiple
header
fields,
right
with
the
same
header
field,
name,.
D
A
K
K
If
all
they
expect
something
that
is
similar
to
post
without
side
effects,
then
we
can
probably
say
this
minor
editorials
tuning.
We
are
done
if
we
are
looking
for
something
which
introduces
proper
cache
ability
of
query
results
and
more
works
needs
to
be
done,
and
I
believe,
every
time
we
look
at
these
issues
we
get
into
the
in
a
working
group
session.
We
get
into
the
details
and
it's
it's
really
not
simple
to
to
define
these
things
properly.
So
I.
A
H
A
O
O
O
To
start
an
upload,
you
use
a
zero
lens
post
request
to
retrieve
a
unique
uri
that
contains
a
server
generated
token.
Then
you
use
patch
to
start
an
upload
to
that
target.
Uri
in
the
case
that
upload
is
interrupted,
you
can
use
the
head
request
to
retrieve
the
upload
offset
and
then
use
patch
again
to
resume
from
that.
Offset
touch
is
a
grid
protocol
and
we
are
using
it
as
a
starting
point
to
build
our
new
protocol.
O
O
O
O
This
protocol
can
be
implemented
both
on
top
of
http
as
an
application
layer
protocol
and
also
within
http
libraries
themselves.
This
allows
existing
adapters.
That
already
depends
on
reservoir
upload
to
switch
to
this
protocol
and
also,
eventually,
everyone
else
can
get
it
when
the
browsers
and
libraries
themselves
implement
this
for
advanced
users.
O
O
O
We
want
to
discuss
the
exact
feature,
detection
mechanism
to
upgrade
from
a
regular
upload
to
a
reservable
upload,
so
we
are
currently
using
a
104
status
code
to
upgrade.
We've
also
discussed
using
http
settings
frame
and
dns
record.
There
are
also
other
options
that
adds
an
additional
round
trip,
such
as
options
requests
or
a
well-known
uri.
O
E
O
O
O
A
N
Okay,
all
right
alessandro,
gadini
cloudflare.
I
have
a
question
about
the
the
client
generated
token.
It
seems
like
it
might
be,
potentially
a
problem
for
a
server
operator
where
you
know
the
server
side
needs
to
be
able
to
guarantee
that
the
token
is
not
reused
across
different
clients
and
also
the
server
might
want
to
encode.
The
information
in
the
token
to
you
know
avoid
maintaining
yeah
certain
stage,
so
it
would
be
better.
O
N
N
B
Mark
it's
your
turn,
so
alexander's
comment
kind
of
touches
on
something
I
wanted
to
talk
about
in
a
little
bit
of
a
higher
layer,
which
is
that
there's
a
trick
to
play
here
where
you
want
to
design
something
and
document
something
that's
interoperable
and
that
works
out
of
the
box.
But
you
don't
want
to
constrain
the
use
of
the
protocol
so
much
that
you
rule
out,
you
know
other
valid
uses.
So,
for
example,
you
know
the
initial
post
to
get
the
token
conveyed.
B
But,
of
course,
they're
extremely
welcome
to
participate
in
the
process.
Likewise,
for
for
people
who
are
you
know
not
the
proponents,
I
was
glad
to
see
the
word
starting
starting
point
used.
You
know
this
is
a
starting
point.
It's
not
the
end.
Point
it'll
go
through
the
normal
process,
and
so
it's
important
that
we
all
have
that
in
mind.
C
Google,
so
first
off
thanks
for
this
presentation,
that
was
great.
It
was
very
clear.
I
think
this
is
useful
and
I
do
think
this
is
a
good
starting
point.
I
think
there
are
some
like
real,
quick,
oh
and
I
have
read
the
draft
and-
and
I
think
it
is
a
good
starting
point-
I
think
there
will
be
some
tricky
questions
to
answer
like.
Should
we
have
the
tokens
and
generated
by
the
client
the
server?
Maybe
we
allow
both,
but
that's
I'd.
Rather
we
do
that
in
the
working
group.
C
V
Alan
from
dell
meta
yeah,
thank
you
for
your
presentation
and
your
draft.
You
know
we
have
had
our
own
version
of
this
reasonable
upload
technology
running,
for
I
don't
remember
how
many
years,
but
many-
and
I
remember
this
topic
coming
out-
that
an
http
workshop,
maybe
three
years
ago,
or
so
it's
something
that
keeps
coming
up
and
honestly
we
probably
should
have
published
a
standard
about
how
to
do
it
a
long
time
ago.
So
I'm
also
happy
that
we're
here.
I
think
we
should.
V
A
Yeah
and
just
looking
at
the
chat,
I'm
seeing
some
others
of
cloudflare
and
microsoft,
echoing
the
same
thing
of
like
we
do
something
like
this
too,
and
it's
always
different,
so
being
interoperable
seems
like
a
good
thing
to
do,
and
it
almost
certainly
will
change.
But
as
long
as
we
are
happy
with,
it
sounds
like
everyone's
happy
with
you
know
letting
the
working
group
have
some
design
team.
A
That's
going
to
actually
figure
out
the
right
thing
to
do,
and
I
think
it'd
be
very
useful
if
those
people
who
have
existing
solutions
in
the
space
would
kind
of
also
present
those
and
explain
those
to
everyone
else.
So
we
can
kind
of
compare
and
learn
from
each
other
if
we
want
to
go
ahead
with
the
work.
H
A
A
A
A
So
dave-
and
I
talked
about
this
based
on
the
feedback
we
got,
and
so
we
revised
the
approach
so,
first
of
all,
what
is
this
for
clients
sometimes
not
always
would
like
to
get
content
that
is
relevant
for
their
general
location,
like
you
want
to
know
where
a
pizza
near
you
is,
or
something
else
and
servers
generally
know
your
location
based
on
your
client,
ip
address
doing
a
geolocation
database
look
up
based
on
your
ip
address.
This
is
assuming
that
you
did
not
do
explicit
javascript
apis
to
share
your
precise
location.
A
A
There
are
cases
in
which
different
databases
have
different
levels
of
supported
specificity.
A
lot
of
them
will
turn
things
that
are
officially
country-wide
or
statewide
into
specific
cities
and
by
choosing
one
at
random
or
choosing
something
in
the
middle
of
a
region.
So
you
can
get
strange
results.
A
A
The
new
proposal
is
to
simply
share
the
gip
database
entry
and
associated
feed
with
the
server
so
that
the
server
can
know
you
know
the
client
has
this
address.
It
thinks
it
got
it
from
here.
It
thinks
it
means
this.
That
is
a
hint
do
with
it.
What
you
will,
and
so
the
format
for
this
is
just
a
structured
field
string
which
is
literally
the
entry,
that's
defined
for
the
gip
feeds,
and
it
can
include
a
pointer
to
the
feed
that
owns
this
particular
ip.
A
This
you
know
it
is
potentially
narrowly
scoped
today
to
cases
where
clients
have
a
way
to
know
what
ipgo
map
they
have.
This
works
very
well
for
a
vpn,
some
sort
of
privacy
proxy,
but
one
could
also
imagine
services
such
that
when
you
receive
your
ip
address
from
your
carrier
or
from
your
isp,
they
could
let
you
know
hey.
A
You
know
I,
my
carrier
uses
their
carrier
feed,
and
this
is
where
they're
putting
you
right
now
and
the
client
only
has
to
share
this
if
they
want
to,
if
they
think
it's
useful,
if
they're
opting
in
on
the
server
behavior
you
receive
this
hint,
there
are
decisions
about
what
you
can
do
with
it.
You
could,
if
you
really
don't
care
you're,
just
trying
to
show
pizza
near
someone,
and
you
just
want
it
to
be
convenient
for
them.
You
could
just
show
them
wherever
they
told
you.
A
You
could
also
easily
filter
this
based
on.
If
you
know
the
feed
is
a
trusted
feed
and
essentially
say,
if
you
had
multiple
options
for
how
to
map
this
ip
address,
that
you
would
prefer
the
one
that
is
actually
authoritative
for
it,
you
could
use
it
as
a
signal
to
re-fetch
your
feed
if
it
mismatches
what
you
have
and
you
haven't
fetched
your
feed
in
a
week
or
a
day
or
some
reasonable
time,
so
that
you're
not
refreshing
constantly,
and
it's
also
potentially
just
a
way
to
flag
cases
of
new
feeds
coming
online.
A
A
N
Alessandro
gadini
klotzler
there
is
definitely
interested
in
working
on
the
problem.
I
haven't
really
thought
too
much
about
the
solution
specifically,
but
I
think
this
is
probably
a
good
starting
point
and
yeah.
I
think
we
should
work
on
this.
I
don't
know
if
you
know
http
base
is
the
correct
place,
but
I'll
leave
that
to
others
to
decide.
F
Bye
sat
yeah.
I
I
agree
that
this
is
an
interesting
problem
to
work
on.
One
piece:
that
of
particular
interest
to
me
is
how
to
think
about
this
in
terms
of
satellite
services,
where
the
relationship
between
the
you
know
the
ip,
if
you
will
on
the
terrestrial
network,
doesn't
necessarily
align
with
the
location,
so
your
isp
knows,
but
it's
hard
in
the
reusable
ip
space.
M
G
I'm
gonna
disagree
with
everyone
who's
gotten
up
here
so
far,
and
so
I
don't
think
this
is
quite
right.
One
of
the
reasons
that
gops
aren't
such
a
problem
for
privacy
is
that
they're,
very
bad
and
trying
to
fix
that
problem
puts
you
exactly
back
in
the
same
box
you
had
with
the
geohash.
Unfortunately,
when
you,
when
you
have
good
geolocation
and
people
start
moving
around,
you
have
the
ability
to
start
tracking
them,
even
with
the
imprecise
information
that
you
have
there.
It
depends
on
the
populations
that
are
in
these
areas.
A
E
B
G
I'm
not
going
to
say
this
is
impossible,
but
we
spent
close
to
10
years
on
this
problem
in
this
organization
in
the
past
and
came
to
some
conclusions
that
or
essentially
it's
very,
very
hard
to
give
away
any
geolocation
information
without
giving
it
all
the
way
and
that
that
is
probably
in
this
case
somewhat,
maybe
less
of
a
less
of
a
case,
because
you've
got
this
intermediate
sort
of
step
where
you're
going
via
ip
addresses,
and
that
has
some
inherent
problems.
And
maybe
those
problems
are
enough
to
keep
people
private.
G
A
C
Yeah
david
skenazi
just
jumping
in
to
respond
as
co-author,
so
I
definitely
think
that
mt
understands
this.
Space
must
much
better
than
I
do
and
that
this
is
a
hard
space,
and
I
would
say
that
if
we
are
unable
to
figure
out
a
tight
privacy
box
that
we
shouldn't
publish
this,
but
I
think
it
makes
sense
to
adopt
and
for
us
to
work
and
see
if
we
can
solve
this
one
potential
exam
idea.
C
Q
A
Q
M
A
C
Hi
everyone
david
scanasi
today,
http
enthusiast,
so
I'm
going
to
talk
about
a
document
that
was
first
brought
to
the
atf
back
at
the
bangkok
one
in
2018,
but
that's
completely
been
rewritten,
and
so
now
I
have
david
oliver
who's
joined
me
as
co-author
and
we're
working
together
on
this,
and
please
ignore
the
title
of
transport
authentication.
It
no
longer
authenticates
the
transport,
so
we
just
haven't
come
up
with
a
better
one.
Next
slide,
please.
C
So
what
is
our
motivation?
We
want
the
client
to
authenticate
itself
to
the
server.
It's
like.
Okay,
great,
that's,
http
authentication
that
already
exists.
On
top
of
that,
we
want
to
use
asymmetric
cryptography,
it's
like
yep.
That
also
already
exists
hoba,
for
example,
but
we
have
yet
another
requirement.
C
C
So
why
isn't
there?
This
already
done
the
fundamental
property
of
asymmetric
cryptography
as
used
for
something
like
this?
Is
that
you're
using
a
signature?
And
you
have
to
sign
something
so
that
can
be
many
things,
but
conceptually
it's
a
unique
nonce,
because
you
want
freshness,
you
don't
want
someone
to
be
able
to
replay
that
authentication.
E
C
Be
signed
and
you
can
go
okay,
yep
you've
signed
this,
and
ideally
you
bind
it
to
the
right
things.
The
problem
with
that
is
most
of
the
scenarios
that
do
that.
You
start
off
and
say
hey.
I
want
to
use
this
authentication.
The
server
says
all
right,
here's
a
nonce,
then
you
say:
okay,
I've
signed
it
and
then
the
server
says
go
ahead,
but
when
the
server
has
sent
you
this
here's
a
nonce,
it's
just
leaked
that
for
the
specific
requests
it
requires,
authentication
and
so
boom.
You
lose
next
slide,
please!
C
So
what
do
we
do?
The
idea
actually
came
from
a
conversation
with
chris
wood
back
then
of
using
a
tls
key
exporter.
Yes,
we're
not
trying
to
reinvent
token
binding.
I
promise
but
yeah
that
it
does
have
that
in
common
and
the
idea
that
the
insight
there
is
the
tls
handshake
contains
fresh
random
data
from
both
endpoints
and
a
key
exporter.
C
Pretty
much
creates
like
random
pseudo
random
numbers
from
both
of
those
random
bits,
and
so
conceptually
we
use
a
key
exporter
not
to
create
a
key,
but
just
to
create
a
nonce
that
the
server
had
input
to,
and
then
you
sign
that
nonce
so
that
you
don't
even
need
to
transmit
it.
The
server
can
decode
it
as
well,
and
you
solve
the
problem
of
sending
your
nonce
without
there.
So
jonathan
do
you
wanna
is.
Are
you
queuing
up
for
later?
Do
you
have
a
question
for
on
this
slide.
S
C
E
G
C
S
C
All
right
cool
next
slide,
please.
So
here's
the
way
the
wiring
coding
looks
today.
You
send
the
signature,
because
you
send
the
algorithm
that
you
used
for
the
signature
and
there's
a
username
in
there,
because
we
figured
that
could
be
useful
for
the
server
to
look
up
in
its
database
of
public
keys
and
yeah
whatever,
like
I'm
sure,
we
can
completely
like
that
if
people
care
next
slide,
please
so
a
note
about
intermediaries
is
obviously
this
is
tied
to
the
underlying
tls
handshake.
C
Will
break
all
is
all
is
good
unless
I
messed
that
up
too,
but
probably
that's
good,
all
right
next
slide,
so
we're
we
have
an
another
independent
implementation
by
the
guardian
project
that
dave
works
on
that
work,
and
so
we're
talking
about
having
this
like
in
various
open
source
projects,
we
figure
it
makes
sense
for
us
to
have
a
place
to
discuss
this.
That
would
be
nice
even
just
from
the
conversation
today.
C
B
You
mark
so
speaking,
just
as
an
individual.
I
think
this
is
an
interesting
area
of
work.
I
think
it's
possibly
important.
Even
I
would
be
so
much
more
comfortable
if
the
draft
were
positioned
in
terms
of
and
the
initial
discussion.
The
working
group
were
positioned
in
terms
of
what
properties
it
has,
rather
than
what
the
solution
is.
That
word,
transport
is
not
helping
you
right
now.
K
C
N
C
N
N
So
there's
two
main
differences.
I
guess
one
is
that's
a
frame.
This
is
not
a
frame,
so
there's
different
use
cases
that,
having
like
a
frame
covers,
like
you
know,
post
request,
authentication
or
something.
If
you
want
to
that,
there
is
the
certificate
frame
uses
certificates
like
x,
509
certificates,
there's
probably
ways
to
to
to
use
raw
public
keys
for
that
as
well.
It
seems
there
were,
it
seems,
like
a
certificate
type
solution.
C
So
my
concern
with
using
a
frame
is
that,
unfortunately,
on
the
internet
today,
http
2
servers
just
explode.
If
you
these,
you
send
them
a
frame
that
they
don't
know
about
which
they're
supposed
to
ignore.
I
get
that
here.
It's
not
absolutely
critical,
because
you're
sending
this
to
a
server
that
you
trust
but
like
I
don't
love
that
also
being
it
prevents
being
able
to
use
it
on
h1
and
when
it
comes
to
certificates.
If
I
can
stay
as
far
away
from
x,
509
as
I
can,
I
would
very
much
prefer
that.
N
L
Alex
tranowski
google,
so
I
have
two
comments
here,
the
first
of
which
is
that
this
absolutely
breaks
in
the
presence
of
intermediaries,
because
the
thing
you'll
be
slower
man.
This
breaks
in
the
presence
of
intermediaries
like
if
you
have
a
reverse
proxy,
because
the
exporter
will
be
running
on
the
reverse
proxy
and
not
the
target.
So
this
is
only
generally
applicable
if
we
can
fix
that.
L
I
didn't
get
there,
but
nonetheless,
that
already
means
that.
I
think
this
is
a
foot
gun
waiting
to
happen
in
the
current
formulation,
which
is
what
gets
me
to
the
the
second
part,
which
is
that
this
authenticates
the
channel
not
the
session,
which
means
that
we
have
additional
cryptography
problems
that
we
need
to
think
about.
When
you
go
to
h2
or
h3.
L
As
I,
as
you
may
know,
I
designed
something
recently
that
used
tls
exporters
for
google
internally
to
do
a
binding
between
the
x509
presented
certificate
and
a
google
internal
certificate,
and
I
think
that
there
is
certainly
a
place
where
tls
channel
exporters
are
a
fit.
But
I
think
we
need
to
think
about
if
we're
trying
to
authenticate
the
channel
or
of
a
session
here
before,
we
can
make
progress.
C
A
E
N
A
W
Example.
Usage
for
this
would
be
logging
or
other
diagnostics.
It
could
be
communicating
rtt
as
seen
from
an
endpoint
or
cpu
usage
that
could
then
be
used
for
load
balancing
by
the
other
end
or
other
internal
use
cases.
So
this
is
not
part
of
the
actual
http
message
itself,
but
it's
about
it.
That's
why
that's
why
it's
meta?
W
So
we
don't
anticipate
a
lot
of
compression
gain
from
using
the
dynamic
table
and
we
did
restrict
the
use
of
hvac
and
would
restrict
the
use
of
cubac
to
not
use
the
dynamic
table
at
all.
We
are
just
using
hpac
for
convenience,
because
it's
something
that
we
have
at
hand
and
we
get
a
little,
maybe
a
little
gain
with
a
huffman
encoding.
W
W
There
can
be
multiple
of
them.
There's
no
limit
on
the
number
of
metadata
blocks
that
can
be
communicated
and
also
there's
no
restrictions
on
the
values
that
each
character
can
take
in
the
key
or
the
value
of
of
the
list
of
key
value
pairs
in
the
metadata
block
notice.
I'm
talking
about
methods
of
blocks
and
not
frames
because
in
h2
there's
a
frame
limit,
and
we
of
course
obey
that
so
a
single
metadata
block
can
be
fragmented
across
multiple
http
2
metadata
frames.
W
A
Opaque
blob
that
you
can
just
transfer
through
here
is
concerning
and
raises
a
few
alarms.
It
seems
to
me
that
you
know
the
mechanism
that
we
have
that
allows
you
to
do
this
like
we
already
have
frames.
Essentially
it's
just
like
a
frame
inside
of
a
frame
to
some
degree.
I
completely
understand
how
it
makes
very
good
sense
within
proprietary
deployments,
where
you're
just
trying
to
say
let's
stuff
things
in
and
see
what
makes
sense.
A
What
is
useful,
what
I
would
be
interested
in
hearing
is
of
the
things
that
you
do
inside
metadata
that
have
become
useful
in
google.
Would
there
be
specific
frame
types
that
you
would
like
to
define
out
of
those?
You
gave
some
examples
of
what
you
wanted
would
want
to
put
in
there.
Nothing
stops
us
from
defining
lots,
lots
of
more
frame
types,
and
so,
if
they
are
useful
frames,
we
could
define
those
there
instead
of
a
generic
metadata
where
you
just
stuff
another
registry
inside
of
it.
M
G
I
was
wondering
if
you'd
get
a
response,
so
martin
thompson,
thanks
for
the
presentation
vince,
it's
always
great,
seeing
getting
an
insight
into
how
the
internals
of
these
systems
work.
But
the
only
thing
that
I
heard
from
your
presentation
was
that
google
has
a
bunch
of
proprietary
extensions
to
http,
2
and
http
3..
G
G
If,
if
there
are
things
that
you
are
doing
here,
that
you
think
is
useful
for
someone
to
use
in
in
in
other
settings,
I
I
would
suggest,
like
tommy
just
said,
a
frame
for
defining
the
exchange
of
that
information,
whether
it
be
on
stream,
zero,
or,
I
should
say
a
control
stream
or
a
request
stream
or
would
be,
would
be
really
interesting
and
so
time
stamps
and
details
of
cpu
utilization
or
whatever.
What
whatever
it
is.
G
W
W
This
thing,
or
we
meant
to
do
this
thing
and
using
metadata
frame
or
a
more
specific
train
type,
would
be
helpful
and
if
no
one
jumps
up
and
says
we
really
want
this.
That's
that's
important
information
for
us
us
as
a
working
group
I
mean
and
the
perfectly
reasonable
outcome
beer
do.
You
have
anything
to
add.
T
So
hello
yeah.
Thank
thanks
for
bringing
this
to
mailing
list.
I
appreciate
those
walls
of
text
I
put
on
there.
I
think
it's
a
good
chat.
I
am
aware
of
use
cases
of
people
trying
to
do
stuff
by
carrying
sidecar
data
alongside
with
requests,
is
really
useful
and
they
struggled
trying
to
puzzle
how
to
do
this,
maybe
even
just
using
their
own
connect
method
and
hacking.
It
and
creating
like
a
weird
chunking
format.
T
Thing
where
actually
like
h2
and
h3
framing
would
have
been
a
much
much
neater
solution
and
I
think
capsule
kind
of
goes
towards
that.
I'm
not
advocating.
We
should
use
capsules.
There's
a
there's
like
a
whole
like
a
spectrum
of
what
to
do
here,
but
the
the
most
generic
thing,
I'll
echo
that
I
just
think
it.
It
opens
up
the
kind
of
wins
with
developers
who
aren't
us
that
they'll
see
it
and
think,
oh,
I
can
start
sending
headers
and
and
do
whatever
I
like,
and
it's
going
to
work
somehow.
C
It's
kanaz
you'll
be
very
quick.
No,
this
is
http.
Sorry,
I
I'm
the
one
who
encouraged
benson
baron
to
come
and
talk
to
the
atf
because
they
were
working
on
this
and
you
know
using
it
we're
going
to
use
it
for
very
real
things
like
google
we're
going
to
be
putting
it
in,
like
probably,
I
can't
commit
to
future
plans
we're
going
to
probably
be
putting
it
into
the
envoy
http
proxy,
which
is
very
widely
used
outside
of
google
and
and
so
my
thought
was:
let's
bring
it
to
the
ietf.
C
Let's
see
if
people
tell
us,
no
one
else
has
a
use
for
this,
then
you
know
we
just
ask
for
the
code
point
and
we're
done,
but
if
other
people
think
this
is
useful
or
can
improve
it,
we're
very
willing
to
take
feedback
and
to
work
with
the
ietf.
So
we
thought
it
would
be
interesting
and
we're
that's.
Why
we're
super
willing
to
hear
any
feedback
and
see
what
other
use
cases
people
have.
B
B
You
know,
request
response
messages,
headers
body,
we
could
add
a
new
construct
to
all
of
that,
and
we've
tried
that
before
with
things
like
server
push,
but
if
we
do
do
that,
it
needs
to
be
something,
that's
really
deliberate
and
I
think
really
well
thought
out,
because
we've
also
frankly
failed
a
lot
when
we've
tried
to
change
the
wire
signature
of
hd
or
the
developer
signature
of
http,
with
even
things
like
pipelining.
That.