►
From YouTube: IETF106-HTTPBIS-20191121-1330
Description
HTTPBIS meeting session at IETF106
2019/11/21 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
Right
so
this
is
HTTP.
This
is
the
note.
Well
once
again,
if
you're
not
familiar
with
this,
you
can
find
this
by
going
to
your
preferred
search
engine
on
the
internet
and
searching
for
ITF
note
well,
and
it
will
tell
you
about
our
expectations
regarding
intellectual
property
and
people's
behavior
and
handling
of
things
like
harassment.
So
please
do
be
aware
of
this.
These
are
all
policies
which
we
do
take
seriously
and
apply.
C
A
That's
fine
agenda
bash,
so
I
wanted
to
do
a
quick
reprise
of
stuff
that
had
happened
in
other
groups.
If
someone
would
be
willing,
I'll
talk
briefly
about
what
happened
in
sac
dispatch,
because
I
was
there.
If
someone
else
could
talk
about
what
happened
in
DNS
op
regarding
the
new
record
type.
Very
briefly,
that
would
be
really
appreciated.
Anybody
wanted
to
do
that.
I
mean
I.
Can
talk
about.
You
can
talk
about
okay,
okay,
then
we
have
a
short
update
on
what
happened
to
continue
to
happen
in
the
priorities
discussion.
A
It's
been
the
bulk
of
our
time
talking
about
our
in-flight
extension
drafts,
and
then
we
have
a
presentation
proposal
for
new
workaround
compression
dictionaries,
which
we
talked
about
before.
This
is
just
a
further
step
in
that
discussion
and
finally,
as
time
permits,
there's
a
proposal
for
a
transport
info
header
that
we
might
get
to
any
other
agenda.
Bession.
A
A
Ht
a
draft
cabbage,
HTTP
request,
signing
I
think
and
there
was
discussion,
insect
dispatch,
I
think
the
information
we
got
there
was
that
there
is
a
fairly
large
community
people
with
with
requirements
in
this
space
and
interest
and
there's
some
forward
impetus,
and
so
the
discussion
there
recommended
that
they
bring
that
draft
here.
So
we
can
expect
probably
a
revised
draft
to
appear
sometime
soon
and
then
we'll
look
at
doing
a
call
for
adoption
or
talking
about
it
more.
A
C
Right
so
in
DNS
up
we
had
a
presentation
from
the
team
working
on
the
HTTP
service
record
or
the
service
binding
record
or
whatever
it's
going
to
be
an
ending
up
being
called
that
document
has
been
presented
here,
but
now
it
has
been
adopted
in
the
DNS
op
group.
It
seems
to
be
progressing
well.
There's
good
discussion
on
a
lot
of
the
details.
There
there's
going
to
be
a
bike
shedding
on
the
names.
C
So
if
people
have
particular
opinions
on
that,
you
can
chime
in
on
that
list,
and
it
looks
like
that's
going
to
be
on
track
to
kind
of
start
finalizing
that
format
and
the
trying
to
get
it
like
an
early
allocation
for
some
of
the
points
there.
So
if
you
I
would
encourage
this
group
to
look
at
the
way
it's
going
to
be
encoding,
ALP,
n
values
and
other
things
make
sure
that
is
in
line
with
what
we
expect,
because
that
may
be
being
locked
down
around
now.
D
Okay,
relaying
an
agenda
bash
yo
vice
asks
if
the
client
hints
can
run
a
little
bit
early
sure.
A
Thanks
thanks
for
that,
he
asked
about
that
earlier.
Offline
I
think
we'll
do
client
hints
first,
when
we
do
the
extensions
and
that
should
hopefully
address
his
needs
since
he's
remote.
Thank
you
so
priorities.
Ian.
Are
you
going
to
cover
that
and
did
you
send
updated
slides?
Is
it
this
one
priorities.
C
C
Had
some
continued
discussions
and
then
lunch
after
the
last
priorities,
discussion
that
ended
up
I,
think
being
quite
productive
and
then
the
authors
and
contributors,
the
sign
team
kind
of
tried
to
make
as
many
updates
through
the
draft
as
possible
and
because
you
have
kindly
pushed
out
a
date
last
night,
which
we
already
got.
Some
good
feedback
on
a
slide.
C
It's
the
same
scheme
we
discussed
before
we
did
a
little
bit
of
renaming.
We
made
a
little
bit
tercer
with
the
expectation
that
you
don't
actually
need
to
spell
out
incremental
and
urgency
or
progressive
to
save
bytes
in
the
wire
I.
Think
Martin
Thomson
has
a
suggestion.
We
can
make
it
Taurus
you're
still,
but
you
know
that's
for
for
later.
That's
kind
of
a
TTL
issue,
but
the
overall
skein
has
not
changed
since
earlier
in
the
week
next
slide.
C
So
I
think
we,
the
gold
that
I
draft
update,
really
was
trying
to
clarify
this
fact.
So,
there's
one
scheme,
it's
the
same
format,
but
there's
two
ways
to
convey
it.
If
you
want
and
end
you
should
use
a
header
and
if
you
want
hop-by-hop,
you
should
use
a
frame
and
those
are
your
two
options.
If
you
headers
are
slightly
more
suited
to
initial
prioritization,
they
can
Betty
send
by
either
side
and
they
allow
you
to
I.
Think
I
lost
some
text
on
that.
One
sorry
it
served
it
over.
I
does
not
make
sense.
C
Just
ignore
that
frames
are
designed
for
reprioritization.
They
can
only
be
sent
by
the
client
or
the
intermediary,
so,
for
example,
in
these
case
we
discussed
before
where
you
want
and
then
signal
what
the
client
priority
is,
but
only
given
hop
you
want
to
say,
like
you
know,
on
this
hop
I
want
a
different
priority.
You
can
use
a
frame
to
reprioritize
the
request,
and
this
fits
exactly
with
the
end
end
versus
hop
by
out
this
diction
next.
A
A
C
Cannot
it
cannot
be
sent
corresponding
to
our
response,
at
least
as
the
draft
is
currently
written,
I'm,
not
sure
if
that
restriction
needs
to
stay,
but
I
think
no
one's
come
up
with
a
killer
use
case
for
it,
so
I
think
we'll
keep
it
well
until
someone
does
so
we
simplified
the
negotiation
using
settings
the
current
goal.
This
went
back
to
the
original
goal
of
the
draft
that
was
at
the
last
IETF,
which
is
if
it's
one
HTTP
two
priorities
are
deprecated
and
urgency
is
supported.
Therefore,
don't
send
those
frames
anymore.
C
That's
pretty
much
all
the
functionality
you're
getting
at
this
moment.
Future
values
could
be
defined
for
the
setting.
If
we
wanted
to,
you
know,
do
other
things
with
it,
but
for
now
it's
really
just
there
to
say,
like
I
support
the
new
thing,
I,
don't
support
the
old
thing,
stop
sending
the
old
thing
and
it
could
be
sent
by
either
side
and
that's
it.
A
C
Was
revived
bust
last
night
right
and
so
that's
as
far
as
you're
concerned.
That's
done
that
encompasses
all
the
changes.
I've
talked
about
they're
in
there
and
it's
it
clarifies
a
variety
of
issues.
I
think
it's
not
done,
I
mean,
of
course,
but
yeah
in
terms
of
reflecting
the
state
of
the
discussion
to
date.
Yes,
I
think
at
least
the
technical
aspects,
yeah,
okay,.
G
That
sounds
good
Martin,
Thompson,
I,
think
kazoo,
who
answered
my
questions
about
the
structure
of
the
they
had
a
field
reasonably
well
I
think
there
remains
a
little
bit
of
question
about
the
frame
and
the
value
of
that
I
raised
that
issue
on
the
list.
I
saw
some
feedback
on
that
point,
but
I
don't
think
that
should
stop
us
from
adopting
this
work.
I
think
that's
enough
of
a
separable
piece
that
we
can
ex
eyesore
enhancers
as
needed.
G
That
there
are
two
mechanisms
that
that
exist
here
and
we've
kind
of
know
a
lot
about
the
first
one
on
robben
point
of
the
research
that
you
did
all
those
wonderful
things,
but
the
other
one
we've
had
for
the
longest
time
and
we
never
had
any
any
anything
to
back
that
in
the
first
place.
And
we
still
don't
have
anything
to
back
that
and
it's
extra
complexity.
So
so.
H
G
I
I
C
K
K
Please
reppin
ya:
roller
marks
I
just
want
to
clarify
that
we
now
also
use
the
frame
for
the
whole
by
hope
semantics,
so
it's
no
longer
just
for
reprioritization.
It's
also
used
for
other
things
that
we
spent
a
long
time
discussing
in
the
design
team,
and
if
you
remove
the
frame,
we
would
have
to
go
back
and
figure
out
that
which
yes.
A
Agreed
I
want
to
stress
that
this
is
a
proposal
from
a
design
team.
I
know
a
lot
of
the
folks
who
are
very
active
were
involved
in
that,
which
is
great,
but
it
doesn't
mean
there's
any
kind
of
consensus
reflected
in
that
and
when
we
do
a
call
for
adoption.
That's
a
significant
affine
that
the
working
group
is
working
on
this
item
now,
not
necessarily
that
we
have
consensus
on
the
contents
of
the
document,
so
that's
the
frame
of
one.
We
should
go
into
this.
A
Of
course,
we're
gonna
discuss
the
issues
we
talked
before
about
the
possibility
of
an
interim
meeting
to
hammer
this
out
had
I
had
a
few
hallway
chats
and
we
talked
about
that
I.
Don't
know
that
that's
gonna
be
necessary
at
this
time,
and
we've
talked
about.
If
we
do,
you
know,
I
think
everyone
once
gets
us
up
pretty
quickly.
Yes,.
F
A
So
if
you
have
any
feedback
on
that
talk
to
Tommy
myself,
but
that's
the
plan
going
is,
is
if
it's
needed.
That's
probably
what
we
will
do
all
right.
Thank
you
very
much
you
so
don't
poke
those
tickets
to
Zurich.
If
you
do
if
this
is
all
you're
interested
in
okay,
my
computer's
still
open
for
attack,
so
I
mean
just
yeah
there
we
go.
A
A
Paging
your
voice,
let's
see,
if
he's
oh,
this
computer
is
or
maybe
frozen,
although
it's
still
reflecting
video.
It
is.
A
L
So
I
realize
five
minutes
ago,
there's
a
slight
slight
ordering
error
in
this.
So
here's
the
slides
finished
way
before
they
do
so
I
fix
out
with
the
PR,
but
I
can
just
do
this
just
to
be
aware
of
it,
so
this
is
yeah
I
just
had
is,
which
was
called
resource
digest,
which
used
to
be
RFC
30
to
30
next
slide.
Please!
L
L
What
that
is,
is
the
application
of
that
algorithm
over
a
the
representation
say
or
some
part
of
body
of
the
or
the
payload
of
the
request
or
response,
but
the
format
of
that
thing
is
dependent
upon
the
digest
algorithm
that
you
view
so
it's
typically
based
64
or
some
other
thing
just
something
to
keep
in
mind
as
we
go
through
next
slide.
Please!
L
So
last
time
around,
when
we
presented
in
Montreal
Roy
asked
for
some
use
cases
we
haven't
put
them
explicitly
in
the
draft
we've
put
in
like
broad
ideas
of
how
it
could
be
used
and
that's
something
I'll
come
on
to
later.
But
today,
as
far
as
we're
aware,
these
are
the
kinds
of
things
that
are
using
digest
mice
signatures,
which
is
an
issue
that
will
it's
all
a
little
bit
more
and
things
like
banking,
api's
next
slide,
please
so
we
had
drafted
o0
and
in
since
Montreal
we've
been
working
on
some
updates.
L
We
had
some
open
issues
that
we
presented
last
time
we've
been
trying
to
address
those,
we
not
fix
them
all,
but
we
have.
This
draft
I
took
a
stubborn
editorial
sweep
before
we
cut
draft.
Oh
one,
we're
aware:
there's
still
some
editorial
issues
we'd
like
to
resolve
the
readability
of
the
document
could
be
improved,
so
I
really
appreciate
any
feedback
on
that,
but
if
people
don't
want
to
take
a
full
read
of
this
document,
that's
fine
because
it's
difficult,
but
if
you've
got
an
opinion
on
some
of
the
issues.
L
We
present
I'd
really
appreciate
feedback
on
that,
because
we
can
resolve
those
and
then
then
figure
out
how
best
to
reword
this
document
or
make
things
better.
So
I
just
wanted
to
deal
with
that.
First,
the
steps
of
the
changes
we've
made
very
quickly
so
one.
The
first
is
clarifying
state
changing
methods
and
the
second
was
a
reboot
of
the
digest,
algorithm
I
on
a
table
and
then
the
third
one
was
a
consideration
section
effectively
for
the
relationship
between
digest
and
s,
RI,
which
stands
for
sub
resource
integrity.
L
L
What
does
clarifying
state
changing
methods
mean
at
issue
853
and
basically,
what
we've
said
is
post
and
patch
requests
convey
actions,
not
partial
representations,
so
a
digest
header
on
a
post
or
patch
request
is
calculated
or
computed
over
the
representation
data
of
the
actions
there
and
in
response
is,
it's
called
deleted
on
the
selected
representation
of
the
referenced
resource.
This
might
be
the
enclosed
one
or
the
selected
representation,
for
example,
in
the
case
of
no
content.
What
does
any
of
that
mean?
L
If
you
go
to
the
next
slide,
we
have
a
post
example,
so
we're
basing
some
stuff
that
some
Jason
and
we
we
tell
the
civil
what
we
would
accept,
but
we
were
posting.
This
thing
title
a
new
title
and
that
request,
sorry
that
I
just
had
a
is
calculated
on
the
enclosed
representation
of
the
request,
the
response
that
comes
back
as
a
different
ash,
because
it's
calculated
on
the
enclosed
representation
in
the
response,
which
is
a
completely
different
thing.
L
If
you
go
to
the
next
one.
This
is
patch.
This
is
very
similar
we're
submitting
a
Jason
patch,
which
is
RFC,
seven,
three,
nine
six.
We
want
a
similar
kind
of
response,
but
the
thing
we're
sending
is
the
same
same
payload
as
the
post,
but
we're
given
the
instruction
to
patch
document
and
therefore
the
response
we
get
back
in
this
case
is
different
than
both
the
patch
document
and
the
representation
from
the
post
example.
D
L
Beat
me
by
two
slides.
So
if
we
go
on
to
the
final
example
here,
this
is
with
the
204.
So
what
this
is
trying
to
show
is
it's
exactly
the
same
digest
header
as
as
the
previous
patch
example
in
the
wrist,
but
we
didn't
have
any
payload.
We
didn't
need
one.
So
this
is
one
of
the
advantages
of
digresses
you
can
inside
this
thing,
so
that
said,
haven't
gone
to
the
FO,
given
some
examples
for
posting
patch.
We
gone
to
the
next
slide.
L
Julian
said:
I.
Don't
think
that
we,
it
would
be
a
good
idea
to
vary
the
semantics
based
on
the
request
method,
and
so
we
can't
address
this
with
some
rewording,
but
should
we
yeah
and
yeah?
This
is
Roberto's
comment.
Does
it
present?
I
guess?
Is
it
present
on
sorry?
Methods
exist
today
or
maybe
invented
in
the
future,
convey
a
partial
representation,
and
if
so,
the
digest
should
always
be
competed
on
the
complete
representation.
That's
probably
some
form
of
the
text
we
might
put
in
there.
L
So
we
we
can
come
back
to
this,
but
if
you
go
to
the
next
slide,
no
next,
like
the
discussion,
doesn't
end
there.
As
you
all
see
so
they
changed
to
this
is
is
really
simple
stuff.
We
have
basically,
as
part
of
the
changes
in
this
document
compared
to
the
URF,
see
that
we're
updating
we
want
to
obsolete
or
deprecated
some
algorithm,
so
we
just
update
the
table
to
have
a
new
column
that
can
contain
this
status
and
we're
deprecating
md5
and
obsoleting
Sean
adlet
32.
L
This
is
something
we
actually
considered
when
getting
the
document
adopted
and
changing
from
the
well
anyway.
We
didn't
because
Mark
told
us
don't
do
that
and
then
to
try
and
address
it
as
as
part
of
0
1
2
0,
0,
0,
2,
0
1
update,
so
that
actually
we
could
incorporate
the
feedback
of
the
working
group
and
all
that
stuff.
So
that
was
fine.
We've
done
some
of
this
stuff,
I
think
it's
all
pretty
straightforward
change,
3!
The
next
slide.
Oh
well,.
M
L
Skip
a
slide:
okay!
Well,
we'll
go
onto
the
open
issues
that
we
we
need.
Input
on,
I
can
go
through
them
all
I,
don't
know
how
we're
doing
at
the
time.
We
probably
don't
need
to
discuss
all
of
them
today.
I
just
want
to
give
people.
Some
awareness
of
the
challenges
were
facing.
If
you
got
any
strong
inspiration
on
helping
us
get
to
that
answer,
it'd
be
fantastic.
L
So
if
you
go
to
the
next
slide,
this
is
cash
digest,
and
cash
validators
you've
got
RC
3213,
stating
that
the
instance
is
specified
by
the
request,
URI
and
any
cash
valid
data
contained
in
the
message.
But
we've
updated
digests
to
use
the
more
recent
ins
in
7230
X
so
rather
than
cash
validator,
we
say
just
validator,
but
how
do
validate
to
specify
a
resource
and
is
specify
their
corrective.
A
Mark
so
you
know
listening
to
the
issues
you
haven't
here.
It
seems
to
me
that
part
of
the
mismatch
here
might
be
that
this
document
is
32.
N
I
mean
it
would.
It
depends
on
what
we
were
talking
about
so
we're
talking
about
what
would
be
on
the
back
end
of
the
server
that
you're
doing
a
cache
or
digest
on
the
back
end
of
what
the
selected
representation
is.
Then,
yes,
you
used
like
the
representation.
If
you're
talking
about
what
you're
sending
in
the
payload,
then
you
would
talk
about
something
else.
Yeah
I.
L
And
be
clear
that
that's
the
the
whole
intention
of
this
document
update
is
to
get
us
a
line,
so
people
aren't
questioning
this
and
we
can
just
get
it
and
get
it
done
and
not
need
to
revisit.
I
think
we
need
to
help
yeah,
so
I'd
be
greatly
appreciated
yeah.
So
next
slide
is
using
digestion
signatures,
so
one
of
the
main
uses
for
digests
is
with
signatures.
We
provide
very
minimal
guidance,
saying
that
you
know
use
some
transport
integrity,
signed
data
and
metadata
avoid
the
broken
algorithms
when
you're
generating
the
digest,
but
that's
it.
L
Some
people
are
saying:
maybe
we
we
could
provide
further
guidance
on
signatures,
especially
related
to
representation
metadata
that
effects
the
selected
representation.
So
what
this
means
is,
if
you're
going
to
calculate
a
signature
over
some
metadata
fields
to
protect
them,
you
should-
and
that
includes
the
digest.
You
should
include
the
other
headers
that
relate
to
that
digest,
but
I
don't
feel
strongly
on.
If
we
really
need
to
do
this
in
this
document
itself,
yeah
none
Thompson
said.
G
L
G
L
L
G
G
Bit
tricky
to
do,
there
is
sort
of
one
level
where
you
simply
say
that
I
want
to
make
sure
that
this
hasn't
been
modified
in
transit.
But
if
you
start
getting
to
the
threat
model
proper,
then
you
have
to
worry
about
the
signature
and
the
and
the
downstream
uses
of
all
of
this,
so
I
would
prefer
not
to
do
anything
on
this
particular
one.
It's
yes
concentrate
on
building
the
building
block
and
then
we'll
worry
about
how
that's
composed
into
various
weapons.
Later
on.
Okay,.
L
Thank
you
our
next
slide,
please,
this
one
is
more
of
a
stylistic
thing:
I
guess,
digests
have
an
empty
representation.
It
sounds
simple,
but
you
know
we're
trying
to
add
some
examples
into
this
document
like
my
lower
them.
So
who
were
to
do
that
just
because
you've
got
an
empty
representation,
doesn't
mean
that
the
thing
that
sent
on
the
wire
is
empty
and
that
affects
the
digestive
al
you
as
is
calculated.
So
here's
two
examples
that
you
know
we
were
taking
an
empty
string.
G
Thompson
again,
it
is
what
it
is
if
the
selected
representation
or
what
representing
rent
owed
better
payload
is
is
a
certain
number
of
bytes.
Then
it's
a
certain
number
of
bytes
and
in
the
compressed
case,
when
you
compress
the
empty
string,
you
get
something.
So
obviously
that's
otherwise.
You
wouldn't
have
this
problem,
so
I,
don't
think
we
need
to
worry
about
it.
Okay,
I
know
that
we
have
something
in
the
in
the
mice
draft
that
specifically
addresses
the
empty
case,
but
that's
because
that
has
specific
requirements
around
that
yeah.
L
And
I'm,
like
I'm,
not
super
familiar
with
this
issue.
If
you
go
on
there,
we
do
link
to
the
discussion
that
happened
between
I,
think
you
jeffrey
and
david
benjamin
and
some
of
those
things.
So
I
think
that's
a
different
problem.
Yeah
yeah!
So
next
slide,
please,
the
this
is
a
fun
one:
the
RSC
3230,
the
one
we're
updating
states
are
following
and-
and
we
just
import
that
text
verbatim
into
the
updates.
First,
so
for
some
algorithms,
one
or
more
parameters
may
be
supplied.
L
L
A
Right,
thank
you
very
much.
Keep
it
up,
I.
Think
this.
The
spec
I've
seen
a
lot
of
activity.
The
editors
have
been
very
busy.
It's
great
I
think
it's
gonna
get
to
a
stage
scene
where
it's
gonna
need
what
a
review
is.
I
think
people
get
engaged
on.
The
issues
now
wants
to
do
a
bit
more
editorial
work.
We
need
better
review
from
folks
Jabar
really.
D
C
D
D
O
P
A
few
changes
to
the
draft
that
has
happened
between
0-7,
which
I
think
was
published
in
back
in
March.
We
clarified
the
define
that
the
define
header,
the
response,
headers
key
references,
the
key
references
with
bangerang
and
replace
the
Aidan
F
pressured
hundred
none
of
that
was
particularly
controversial
as
a
result
of
feedback
that
we
got
at
the
ITF
105.
We
remove
the
explicit
except
CH
lifetime
header
and
replaced
it
with
implicit
registration
that
is
tied
to
the
life
of
session
cookies.
P
Q
P
Another
PR
that
has
just
landed
as
a
result
of
feedback
is
to
add
the
basic
outline,
the
bite-size
cost
of
adding
hints
and
therefore
cautioning
implementers,
as
well
as
servers
that
you
know
hence
have
a
cog
and
therefore
they
should
be
used
in
moderation
next
slide,
and
we
have
a
couple
of
and
the
key
ours,
but
I
believe
recruit
to
being
done.
But
I
would
love
the
group's
opinion
on
them
and
what
more
is
needed
there?
One
is
detailed
I
mentioned
of
information.
P
Outlines
exactly
what
categories
of
information
can
be
exposed
in
client
hints?
What
categories
of
information
must
not
be
exposed
as
a
client
hint
and
define
what
implementers
and
feature
that
we'll
be
using
this
infrastructure
and
I
shouldn't
take
into
account
when
doing
that,
so
I
believe
this
is
close
to
being
done,
but
I'd
love,
opinions
from
from
the
group
and
particularly
Martin,
Thompson
I,
know
like
you've,
been
active
on
this
issue.
I'd
love
to
know
if
there
is
anything
else
that
needs
to
be
done
there,
so
that
we
can
wrap
it
up.
P
G
G
That's
really
the
property
that
we're
looking
for
and
part
of
part
of
the
the
concern
that
we
have
is
that
if
we
allow
sites
to
set
arbitrary
headers,
particularly
in
cross-origin
requests,
then
the
server
at
the
other
end
may
be
unprepared
to
receive
those
particular
header
fields.
It
may
do
something
that
maybe
we
are
uncomfortable
with
the
consequences
of
it
might
be
a
security
vulnerability
who
knows-
and
that
is
coupled
here
with
the
desire
to
have
these
header
fields
available
on
the
very
first
cross
origin
request
made
to
any
given
origin.
P
G
P
G
Right
so
I
guess
this
is
a
bit
unfortunate,
but
I've
been
having
a
bunch
of
discussions
with
Alabama,
Karen
and
and
others
about
what
it
is
that
we
do
with
origin
policy,
other
ways
of
signaling
origin
policy,
potentially
using
things
like
a
flag
and
that
in
the
taillights
handshake.
That
indicates
that
this
service
willing
to
willing
to
accept
the
consequences
of
dealing
with
things
like
the
pre
flights
itself.
F
G
Examples
but
I
think
that
that
having
that
capability
is
something
that
I
would
prefer
to
keep,
even
if
it
means,
maybe
in
the
short
term,
having
this
exposure
to
the
necessity
of
pre-flight
until
we
have
a
better
understanding
of
how
this
works.
I
realized
that's
kind
of
springing
on
you
love,
but
that's
all
discussions
I've
had
in
the
past
week
or
to
try
to
try
to
chase
this
particular
problem
down.
It's
really
quite
a
funny
one.
Okay.
G
G
The
time
that
it's
going
to
take
or
the
amount
of
space
is
going
to
gonna
need
that
sort
of
thing,
or
maybe
it
wants
to
prepare
for
a
situation
where
it's
in
a
more
limited
context,
or
maybe
it
wants
to
move
that
that
data
elsewhere
and
give
it
to
a
more
constrained
device.
I,
don't
know,
but
it
has
these
constraints
on
on
the
data,
and
it
wants
to
express
that
and
use
the
client
hints
and
hit
the
cache
in
the
right
way
and
all
those
sorts
of
other
wonderful
things.
So
that
was
the
example.
G
P
G
So
that's
one
reluctant
to
do
because
that
means
that
now
you
have
two
things
that
essentially
mean
the
same
thing
but
they're
distinguished
based
on
where
they
came
from
and
we
have
to
carry
that
baggage
forever.
I
I
realized
that
this
is
unfortunate,
but
I
would
I
would
rather
try
to
solve
the
problem
than
have
to
have
to
deal
with
it
in
this
in
this
kind
of
ugly
way.
The
sec
prefix
is
kind
of
horrific,
and
it's
a
blunt
instrument.
Unfortunately,
and
that's
what
I'm
trying
to
avoid.
P
Any
more
yes,
so
next
slide
is
basically
I.
Would
love
to
see
that
infrastructure
draft
move
further
along
I
am
planning
to
ship
user
agent
client
hints
in
chromium
very
shortly,
based
on
the
new
infrastructure.
That's
outlined
in
this
draft,
as
well
as
the
feature
policy
really
the
infrastructure
of
cross-origin
delegation,
so
I
would
love
to
see
this
move
further.
F
G
Here
and
I
confess
I
was
unable
to
find
any
of
them
when
I
went
looking
the
other
day,
so
you've
done
a
great
job
of
removing
them.
They
seem
to
have
disappeared
from
the
internet,
but
we
that
means
that
we
probably
can
not
concentrate
on
whether
the
sec
prefix
is
something
that
we
use
and
simply
say
that
we
have
to.
G
P
C
The
other
one
it
looks
like
mainly
the
comments
on
there
were
seeming
to
be
about
the
fact
that
we
are
adding
kind
of
normative
text
in
you
should
avoid
these
various
fingerprinting
surfaces
without
really
giving
you
mechanisms
to
do
that,
and
so
it
seems
like
it's
problematic,
to
add
normative
text.
To
tell
you
something
that's
under
specified.
Do
we
have
comments
here
or
do
we
know
how
to
progress
on
this
issue?.
G
G
A
A
F
F
So
the
first
thing
I
did
was
to
better
define
which
fields
should
be
signed
together
with
digest,
with
metadata
should
be
signed
together
with
digest
and
then
started
working
and
rewriting
that
I
just
had
I
think
that
it's
worth
when
specifying
the
digests
raft
to
give
guidance
about
using
digest
with
signatures,
because
actually
there
is
an
issue
by
for
the
implementers
about
all
the
contest
and
all
the
the
metadata
that
are
part
of
the
of
the
the
essential
to
decode
the
epilogue,
because
the
payload
is
not
the
representation
that
that's
it.
Thank.
A
I
want
to
make
sure
that
it's
usable
both
for
the
implementations
that
are
produced
in
the
header,
as
well
as
people
consuming
it
to
do
things
with
it
and
I
think
we
need
to
probably
do
at
least
one
more
revision
for
that
latter
class
of
people.
But
one
thing
I
want
to
highlight
here
is
is
that
we
made
a
pretty
fundamental
change
last
time
there
was
a
tag
that
kind
of
held
the
semantics
of
what
happened,
and
then
there
was
a
parameters
on
that
that
were
identifying
various
parameters,
including
the
name
of
the
node.
A
So
what
the
name
of
the
cache
was
that
is
claiming
that
this
action
has
taken
place.
We
flipped
that
and
the
the
primary
token
here
that
you're
putting
parameters
on
is
the
identity
of
the
the
party
taking
the
action.
So
in
this
case
it's
example
cache,
and
then
you
know
here
it's
a
fresh
response
and
so
forth
and
so
on,
and
so
I
wanted
to
highlight
that
to
folks
to
make
sure
that
we're
comfortable
with
that,
because
I
think
we
should
probably
do
the
same
thing
in
the
proxy
draft
who's
read.
A
A
Is
close
by
this
commit?
Where
was
it's
just
I'm,
not
sure
that
it's
sticking
yet
I
think
we
need
to
continue
to
refine
refactoring
I?
Didn't
that's
why
I
didn't
close
it?
So
please
take
a
look
and
review
and
I'm
gonna,
probably
noodle
on
it
a
bit
more
and
we'll
have
another
draft
sometime
soon
any
comments
on
the
cache
draft.
We
aren't.
We
changed
the
name
by
the
way
we
did
close
that
issue
its
cache
status
now.
S
A
Okay
and
that
takes
us
to
proxy
status,
Peter
and
I
have
been
working
on
this.
In
the
background
and
having
a
chat,
we
have
two
issues
left
we
haven't.
We
did
not
publish
a
new
draft
before
this
ITF
because
we
wanted
to
get
to
conclusion
on
this
first
and
assuming
that
we
can
make
the
change
we
just
talked
about
I.
Think.
A
This
issue,
we
went
to
a
place
where
we
were
talking
about
splitting
into
two
different
headers
proxy
status
to
reflect
the
the
terminal.
You
know
this
is
an
error
generated
by
a
proxy
and
then
proxy
info
to
capture
information
that
the
proxies
observed
on
the
way
through
and
I
think
that
if
we
make
that
change
that
we
made
with
cache
status,
we're
not
going
to
need
to
split
it
up
into
I
suspect
we're
to
be
able
to
leave
it
within
two
one
header
which
I
think
makes
everyone
happy.
A
D
Is
this
about
this
draft
fish
about
cash?
Oh,
please,
go
ahead.
Chris
lemon
says:
I've
read
it
I,
really
like
the
reformulation.
I,
don't
see
the
extensible
case
in
there
I'd
like
to
see
a
place
to
put
some
data
about
what
kind
of
a
hit
it
was,
for
example,
a
hit
on
disk
RAM
or
some
other
place,
I'd
like
to
see
proxy
status
to
follow
suit.
Okay,.
A
So
if,
if
that's
the
case
and
we'll
do
that,
refactoring
again
on
this
spec
and
then
hopefully
we'll
be
able
to
close
8:21
without
much
that
leads
us
to
808
and
there's
a
back
and
forth
here
in
piano
field,
please
feel
free
to
come
to
the
mic.
To
represent
your
view.
We've
been
talking
the
background,
a
lot
and
then
there's
there's
attention
here.
I
think
you
know.
One
of
the
comments
was
that
that
being
able
to
identify
requests,
errors
and
different
kinds
of
requests,
errors
that
are
currently
identified
by
H
to
be
status
codes.
A
You
know
whether
it's
forbidden
or
URI,
too
long
or
whatever
is
useful
to
do
here
into
a
court
here,
and
so
we
started
to
walk
down
a
path
where
we
had
a
code
for
each
of
those
states,
and
you
can
see
I
did
a
I
started
to
do
this
in
the
draft
itself,
and
so
we
have
all
these
new
things
associated
with.
Oh
sorry,
yeah
here
we
go
all
these
new
HTTP
requests
ones
from
here
down
one
code
for
each
existing
HTTP
status
code
and
I'm
not
done
with
that.
A
Q
Might
depend
on
that
so
I
think
this
was
more
of
an
issue
in
current
state
when
we
have
dedicated
types
that
are
a
primary
object.
If
we
do
the
refactoring
and
switch
to
the
proxy
name
being
the
primary
identifier
and
switch
this
to
us
to
being
key
values
right
like
status
and
status
price,
we
don't,
we
can
just
piggyback
okay
on
an
existing
service.
Kasam,
don't
need
to
read
the
find
so
I
think
then
it's
fine,
okay!
So.
A
That
would
I
think
we
talked
about
this
briefly,
so
that
would
take
us
to
a
design
where
we
originally
had
one
of
these
codes.
That
was
HTTP
request,
issue
or
whatever,
and
then
it
had
additional
parameters
that
convey
the
status
code
and
the
status
phrase,
so
that
you
can,
you
can
find
out,
but
you
know
it's
just
look
at
the
status
code.
Of
course,
I
know.
A
I
forget
what
we
call
them,
but
the
proxy
they're,
our
status,
things
yeah,
okay,
so
I
think
we
can
kind
of
write
that
down
and
see
what
it
looks
like
it
make
sure
everybody's
comfortable
with
it
and
then
before,
but
it
if
we
can
solve
these
two
issues.
I
think
we're
in
agreement
that
we're
pretty
much
ready
to
go
right.
It.
C
G
Right
so
mum,
Thompson,
I
I,
think
if
you're
making
requests,
then
it
makes
perfect
sense
to
just
record
the
status
code
that
you've
got.
If
that's
all
the
information
that
you
have,
if
there's
other
error
conditions
that
might
be
generated,
then
you
have
them
other
values
that
you
can
have,
but
I
think
having
a
having
I
made
a
request
and
the
and
the
status
was
X
as
part
of
the
information
that
you
provide,
which
may
even
be
in
addition
to
the
other
errors
that
you
might
stick
in.
There
is
much
cleaner.
C
A
C
A
A
Don't
think
it's
seen
a
lot
of
review.
So
if
people
could
please
take
a
look
at
that,
that
would
be
fantastic.
There
are
a
couple
of
issues
here
which
I
think
are
pretty
manageable,
so
my
anticipation
is
I.
Want
to
play
when
I
have
an
old
implementation
of
this.
That
I
want
to
refresh
make
sure
it
works
properly.
Make
sure
that
the
draft
is
reasonable
and
then
I'm
thinking.
We
should
probably
publish
this
as
experimental
and
see
how
that
goes.
A
We
did
have
some
implement
or
interest,
but
for
a
lot
of
reasons,
it's
not
really
getting
that
and
I.
Don't
hang
around
too
long
I'd
be
interested
to
hear
if
people
feel
differently
about
it.
If
they
want
to
just
keep
it
hang
grandma's
draft
or
oh
I,
have
an
implementation
or
I'll
do
one
honest
or
whatever.
G
Nan
Thompson
I
realized.
This
is
probably
drawing
too
long
about
it,
but
W
Peck
work
was
more
or
less
depending
on
this
one
I
know
would
it
would?
It
seems,
like
the
outcome
of
that
work
would
be,
ideally
would
be
a
standard
track
document
and
having
that
standard
take
document,
and
not
an
experiment,
is
a
little
awkward
I
think
we
must.
We
might
need
to
be
prepared
to
revise
this
in
a
fairly
short
timespan
if
it
gets
more
serious
over
that
way.
A
M
Very
much
in
my
mind,
this
is
Jeffrey
askin
in
the
W
Peck
kind
of
experimental
implementations.
We
are
suffixing
variance
with
the
draft
number,
which
seems
like
a
good
way
to
proof
kind
of
the
experiment
if
it
gets
published
as
an
experimental
RFC
and
then
needs
changes
before
it
goes
to
standards
track.
Is
there
we
need
to
come
up
with
a
migration
plan
for
the
kind
of
what
Evers,
whatever
is
released,
sure.
A
We'd
have
to
come
up
with
different
header
names
if
it
needs
changes,
yeah
and
that's
not
terribly
Pleasant
yeah
I
mean
to
be
clear,
I'm
perfectly
fine
parking
it
for
a
while.
If
that
lines
things
up
a
bit
better
I
just
want
to
make
sure
that
everybody
is
comfortable
with
a
Marc
document
for
that
long,
because
if
this
is
the
negging
out
there
for
a
little
while.
G
A
They
expire
question
I
think
it
was
in
this
very
room:
okay,
well
I.
Certainly
I
have
issues
to
address.
It
has
a
dependency
on
core,
so
it's
not
gonna
ship
anytime
soon,
anyway,
I'll
do
a
revision.
I'll
do
some
some
prototype
implementation
to
make
sure
that
everything
still
works
properly,
but
I
will
there
on
the
Shelf
after
that
and
wait
for
feedback,
I,
think
and.
C
A
G
Mumtaz
and
I
don't
agree
with
that.
Any
anything
we
might
learn
and
we're
packaging
would
be
helpful,
but
I
don't
think
it's
gonna
be
dispositive
in
any
of
this,
because
this
is
targeted
at
intermediaries
and
if
intermediaries
don't
prove
that
they
can
use
this,
then
we
still
don't
know
anything.
Okay,.
A
A
C
A
Well,
definitely
need
to
do
another
worker,
blast,
calmness
and-
and
you
know,
I
after
I
did
I
had
misgivings
about
all
these
changes,
but
as
after
I
did,
I
looked
and
I
was
happy
with
the
documents
resolved.
That's
yeah,
I
think
it's
the
right
thing
to
do.
Random
access
is
not
our
problem
anymore,
and
it
should
be
out
the
door
as
an
actual
RFC
very
very
soon
it
has
secondary
certificates.
C
J
Actually,
I,
don't
think
we'll
take
that
long.
So
there's
not
a
whole
lot.
That's
happened
in
the
document
itself.
Last
time
around,
we
finally
came
to
a
compromise
on
what
we
want
to
do
for
the
DNS
pieces
and
really
the
outstanding
piece
right
now
is
implementations
I'm,
aware
of
all
of
one
implementation
of
this
and
it's
server-side.
Almight
I
have
two
other
possible
interest
in
implementing
that.
J
U
G
Mom
Thomson
I'd
really
like
to
be
able
to
implement
this
one,
but
it
has
remained
below
the
the
floor
of
various
other
higher
priority
things
for
for
a
long
time.
I
think,
like
the
variants,
work,
I'm
comfortable
parking,
this
one
I,
don't
want
to
publish
this
one
as
experimental
I,
don't
want
to
I,
don't
to
publish
anything
that
hasn't
been
tested
in
the
field
in
particularly
in
this
area,
and
there's
there's
a
number
of
things
in
here.
G
That
I
think
will
require
some
care
in
order
to
get
right
and
we
may
want
to
make
some
sort
of
minor
tweaks
as
we
as
we
go
through
deployments.
So
my
preference
here
is
to
just
say:
okay,
fine,
it
sits
there
and
it
can
sit
there
at
the
bottom
of
this
list
for
the
next
three
years.
If
you
really
like,
we
don't
have
any
open
issues.
Do
we.
J
L
U
Kyle
nekritz-
I
think
I
might
have
mentioned
this
last
site
if
we
have
a
like
half
completed
client
and
server
implementation,
but
yeah
there
hasn't
really
been
any
movement
on
that
in
the
past
year.
So
and
I'm
not
sure,
there's
going
to
be
any
any
any
time
and
then
a
very
near
future.
But
I
have
no
problem
with
what
the
plan
Martin
suggested
from
what
we
did
get
done.
We
didn't
find
any
kind
of
real
issues.
In
effect,
though,.
V
Yeah
I
think
not
publishing
and
not
killing
is
the
sorry
Pat
McManus
I
think
not
publishing
in
killing
is
probably
the
right
path
here.
I.
There
are
a
number
of
use
cases
being
sort
of
explored
on
this,
but
it's
a
delicate
thing
to
deploy
even
at
a
test
level.
So
I
certainly
don't
want
to
see
it
deprecated.
So
we
have
something
to
work
off
of,
but
yet
publishing
it
without
the
experiences
probably
yeah
and
ego.
V
A
Yeah,
it's
like
okay,
expect
CT,
that's
not
see.
Now,
isn't
it
no.
A
F,
oh,
that
makes
sense.
I've
got
structured
headers,
so
we
have
been
chucking
away
at
this.
Our
issues
list
we're
just
doing
some.
Some
I've
done
an
editorial
pass
through
it
and
there
are
a
couple
of
knits
left
over.
The
only
real
discussion
we
have
left
is
around
floats.
We
still
have
a
little
bit
of
discomfort
around
exactly
what
floats
are,
and
especially
since
you
know
the
on
wire
representation
and
the
model
for
that
is
somewhat
different
from
what
people
are
using
implementations
and
making
sure
we
get
those
mappings
correct,
so
that
discussion
continues.
A
I,
don't
know
that
it
makes
sense
to
go
too
deep
into
that
here,
but
we
do
have
a
pretty
active
discussion.
There
I
think
we're
gonna,
probably
rename
float
to
decimal.
It
seems
to
be
that's,
that's
the
the
sense.
If
folks
have
thoughts
about
that,
I'd
love
to
hear
it,
we
do
have
multiple
implementations.
A
We
have
our
test
suite
with
almost
1500
tests
in
it
now
I
recently
got
my
implementation
doing
both
the
pars
again
serialization
parts,
half
of
that
working,
which
is
great
and
I,
think
it's
being
implemented,
at
least
in
the
civilization
side.
In
chrome
by
in
income,
so
that's
good
Martin.
G
G
We
discussed
this
at
the
last
meeting
and
it
seemed
fairly
clear
that
people
were
happy
with
the
effectively
a
fixed
point
decimal
right.
But
what
came
up
in
discussion
was
that
that
would
result
in
being
unable
to
express
certain
types
of
information
such
as,
for
instance,
the
number
of
nanoseconds
since
the
UNIX
epoch
milliseconds
would
be
equally
bad,
I
think,
maybe
maybe
there's
microseconds
I
don't
know,
but
that
seemed
to
be
the
the
thing
that
motivated
the
change
to
go
to
a
floating-point
number
I.
Think
that's
a
bad
decision,
yeah!
G
A
O
A
Personally,
for
me,
the
high
order
bit
in
this
is
that
if
we
have
a
flow
to
our
decimal
type
or
whatever,
it
needs
to
be
able
to
represent,
what's
in
carnage,
to
be
headers,
if
we
want
to
map
them
to
structured
headers,
which
is
I,
know
not
completely
in
scope
for
this,
but
it's
an
Intendant
future,
and
that
means
mostly
Q
values.
I
think
I,
don't
know
of
any
other
big
places
where,
where
decimals
are
used
in
HTTP,
headers
and
Royce,
getting
up
the
correct
thing
so
so
I'm
getting
them
from.
G
Q
values
give
values,
Q
values
yeah,
so
I'm,
not
getting
from
from
that,
that
we
need
a
huge
dynamic
range
on
these
values,
which
suggests
that
we
could
go
with
something
a
whole
lot
simpler,
but
it
seems
like
the
discussion
that
went
on
on
the
list
was
quite
quite
firmly
down
the
path
of
well.
We
need
we
need
this
bespoke
floating-point
format.
N
G
So
I
guess
I
I
guess
the
real
question
here
is:
if
we're
going
to
express
times
as
as
numbers,
what
are
we?
What
do
we
think
we
might
want
to
do
in
the
future
about
that,
and
is
that
sufficiently
different
to
the
use
cases
we
have
for
say
Q
values
that
we
can
worry
about
that
problem
at
that
future
time
right
well,.
G
A
Hazy
until
someday
far
far
far
in
the
future,
because
we've
got
15
digits
to
work
with
yep
in
integers
in
structured
and
then
there's
if
I
want
to
introduce
a
new
field
that
has
something
like
millisecond
time
in
it.
Hey
there's
a
question
of
whether
that's
a
good
idea,
which
has
always
been
a
contentious
issue
in
HTTP,
assuming
that
it
is
a
good
idea,
you
don't
have
to
start
with
floating-point.
You
could
start
with
an
integer
and
say
this
is
the
integer
number
oh
you're,
making
my
arguments
for
me.
A
A
So
this
has
been
contentious
and
I
think
it
brought.
We
can
make
a
proposal
and
list
it's
gonna
come
up
on
last
or
on
the
issue,
I'd
like
to
get
a
better
sense
of
the
room.
Personally
I.
Think
the
precise
number
of
digits
is
a
bike
shed
agreed,
no
I
mean
about
it
being
becoming
a
fixed
point.
So
could
we
get
a
sense
of
the
room
yeah.
G
C
First,
we'll
ask
if
people
would
like
to
switch
to
used
fixed
point
for
anything
that
is
a
fractional
number
and
then
the
second
question
will
be
if
you
prefer
to
use
floating
point
as
we
do
today
and
try
to
figure
out
that
world
alright.
So
please
hum
now,
if
you
prefer
to
switch
to
fixed
point
and
please
hum
now,
if
you
would
prefer
to
use
floating
point
okay,
so
for
the
minutes
it
was
stronger
for
fixed
point.
There
was
some
humming
for
floating,
but
if.
A
A
A
D
A
Me
I
think
I
have
an
action
to
go
and
engage
with
the
other
people
who
aren't
here
and
who
have
been
active
on
the
spec,
as
well
as
the
communities
that
have
started
to
adopt
structured
headers
because
there
are,
they
are
out
there
I,
don't
think
any
of
them
are
using
floating
yet,
but
I
want
to
double
check
and
make
sure
that
this
doesn't
cause
concern
those
communities
so
we'll
see,
but
from
a
interoperability.
Standpoint
personally,
I
feel
better
about
fixed.
W
A
G
I
guess
the
argument
against
doing
something
like
that
is
that
this
is
fairly
tightly
coupled
into
the
into
the
numeric
serialization
and
parsing
routines
that
that
you
have
in
the
spec
and
so
having
it
integrated
into
the
spec
makes
it
a
lot
easier
to
be
sure
that
people
get
that
distinction
between
the
two
of
them
correct,
whereas
in
an
extension
we
might
have
to
think
about
having
a
different
flag
to
go
at
the
front
of
it
in
order
to
properly
distinguish
it
from
other
types
of
fields.
And
that
sort
of
thing
that's.
A
A
Of
course
it
can,
but,
but
it
you
know
so,
I
have
a
separate
draft
which
is
not
in
scope
for
this
working
group
now,
which
is
how
do
you
back
port,
existing
headers
on
to
structured,
headers
and
a
lot
of
value?
A
lot
of
headers
use.
Key
values
would
be
nice
to
be
able
to
not
require
different
serialization
of
them.
R
Gothics
I'm
wondering
if
it
would,
if
the
only
use
case
for
this
is
Q
value,
is
I'm
wondering
if
a
much
tighter
drier
structure
that
can
only
represent
values
between
0,
&
1
rather
than
arbitrary
floating
point
would
be.
It
would
be
the
right
data
type
here,
I'm,
seeing
shaking
heads
and
I'm
wondering
why
I.
A
Think
if
we're
gonna
go
to
the
point
of
describing
something
decimal,
you
know
saying:
okay
well,
fixed
point
decimal
numbers
that
has
utility
still
without
a
lot
of
work
and
older
and
again
the
interoperability
profile
is
still
pretty
tight
so
or
just
as
tight
I
want
to
check
this
HTH
real,
quick,
I
think
everything
here
is
done,
except
for
like
oh
yeah,
that
was
the
decimal
thing
yeah.
So
please
do
have
a
look
at
the
spec
Delta.
That
issue
I
think
it's
pretty
much
ready
to
go.
A
A
A
A
So
sixty
to
sixty-five
this
is
still
an
open
document.
We
still
have
a
number
of
open
issues
on
it,
I
believe
there
we
have
1818,
so
I
think
we're
gonna
have
a
chat
with
the
editors
again
about
that
and
figure
out
yeah
how
we
can
move
that
forward.
I,
don't
think
we
have
anything
to
report
at
this
meeting
because
there
hasn't
been
any
activity,
but
we
need
to
see
a
way
to
get
that
to
conclusion,
somehow
any
other
comments
on
our
open
extension
drafts.
I
think
that
covers
everything.
D
D
D
Achieving
the
best
compression
ratio,
the
choice
of
algorithm,
plays
an
important
role,
but
once
you've
done
that
I
believe
that
compression
dictionaries
are
the
next
frontier
and,
as
you
can
see,
we've
seen
pretty
significant
way
in
deploying
our
own
content
coding
at
Facebook.
Next
slide
for
those
unfamiliar.
D
For
those
unfamiliar
dictionary
based
compression
is
this
technique
where
you
provide
some
external
state
to
the
compressor,
and
it
can
use
that
to
produce
a
more
compact
representation
of
the
message
when
we're
talking
about
a
response
body
compression
we're
usually
talking
about
an
LZ
compressor,
so
the
dictionary
is
basically
content
that
you
can
make
string
matches
against.
So,
rather
than
having
to
represent
some
string
in
the
compressed
message,
you
can
just
omit
a
reference
to
the
dictionary.
D
This
technique
does
have
drawbacks
and,
in
particular
the
blocking
problem
in
previous
attempts
has
been
concerns
about
introducing
new
security
vulnerabilities
next
slide.
Nonetheless,
I
think
this
is
something
we
should
do.
We
should
standardize
and
deploy
a
dictionary
based
content
coding,
I
hope
to
work
with
you
all
to
do
that
in
the
future,
but
it's
become
clear
that
first,
in
order
to
do
that,
we
need
to
better
understand
the
security
properties
of
the
domain.
X
slide.
D
D
It
lists
the
security
questions
that
arise
as
a
result
of
both
that
compression
and
the
surrounding
mechanisms,
and
finally,
it
lists
mitigations,
where
they're
known
so
in
investigating
the
security
properties
in
this
domain.
I
think
there
are
two
categories
that
are
worth
talking
about
next
slide.
D
Next
slide,
so
this
attack
applies
just
as
well
to
dictionary
based
compression,
which
is
a
concern,
and
actually
possibly
even
more
so
because
dictionary
based
compression
is
precisely
the
process
of
taking
two
different
pieces
of
content
and
putting
them
in
the
same
compression
window.
So
it
potentially
creates
new
avenues
towards
mixing
attacker
and
user
data,
so
that
requires
careful
consideration
next
slide.
D
D
So
this
is
the
list
of
kinds
of
attacks
that
the
document
currently
discusses.
I
tried
to
figure
out
how
I
could
say
more
meaningful
things
about
these,
without
using
vastly
more
than
my
allotted
time.
So
instead,
I
will
just
refer
you
to
the
document
which
discusses
them
in
some
detail
next
slide,
and
so
that
leaves
me
with
the
question:
is
this
work?
Does
this
work
belong
in
HTTP
this
and
if
so,
what
is
the
path
towards
adoption
from
here?
So
thanks
next
slide,
I
look
forward
to
hearing
your
thoughts,
questions
comments.
A
Thank
you
very
much
so
for
folks
who
have
been
here
for
a
while.
You
know
that
we've
had
this
discussion
in
several
ways.
Over
the
years
there's
a
lot
of
folks
interested
in
you
know
doing
dictionary
based
compression
in
HTTP.
There
was
always
this
roadblock
of
what
are
the
security
properties
of
it,
and
so
thank
you
so
much
for
for
doing
such
a
fantastic
job
and
trying
to
write
that
down
and
document
that.
So
we
can
continue
that
discussion.
A
I,
don't
know
that
we
can
come
to
any
answers
today,
but
I'd
love
to
hear
what
people
are
thinking.
You
know
who
we
see
if
show
henan
who's
read
the
document
so
far.
Okay,
so
it's
mattering
across
the
room,
I'm
hoping
we'll
have
more
people
read
it,
so
we
can
continue
that
discussion
go
ahead
right
so.
D
A
So
there
might
be
a
question
of
at
least
coordination
with
the
security
area
there
to
see
if
they
want
to
take
first
pass
at
it
or
yeah.
We
can
talk
to
where
a
director
and
talk
to
the
security
area
directors
and
see
what
they
think
you
didn't
talk
about.
This
that's
act,
dispatch
at
any
point.
Did
you
okay,
any
other
thoughts
for
folks,
okay,
I
see
thumbs
up.
Thank
you
again
for
doing
that
and
we'll
have
some
background
discussions
to
figure
out
what
the
next
steps
in
that
discussion
are.
A
T
So
I'm
James
Christian
from
the
BBC
I,
would
like
to
introduce
a
new
header
to
represent
transport
information
next
slide,
please
so,
including
various
states,
like
you
know,
at
each
of
the
connections.
Rtt
are
the
sender's
congestion
window
and
I
want
to
do
this
for
a
couple
of
reasons.
It's
for
clients
that
can't
get
this
directly,
particularly
for
JavaScript
inside
of
web
browsers,
or
perhaps
revealing
information
about
the
connectivity
between
CDN
and
origin.
T
There
is
already
a
w3
standard
called
net
info,
but
for
a
bunch
of
reasons
it
doesn't
expose
a
lot
of
this
information
and
it's
not
it's
not
extensible.
We
don't
want
to
do
this
exclusively
for
TCP.
We
could
do
it
for
quick
or
anything
else,
and
we
also
allow
for
multiple
samples,
so
that
are
all
time
and
time
based
next
slide.
Please
a
couple
of
examples
here
really
quickly.
T
If
you
don't
understand
what
I'm
saying
that's
roughly
what
they're
looking
like
next
slide,
there
is
a
couple
of
issues
in
a
0-0
draft
that
were
already
aware
of
such
as
how
to
deal
with
connect
proxies
a
LPN
might
be
problematic
because
for
non
h2
or
h2
and
lower
the
it's
not
clear,
it
won't
be
clear
to
the
receiving
and
whether
or
not
TLS
is
being
involved.
Our
current
represent
a
of
time
is
probably
over-engineered
and
there.
Maybe
it's
not
clear
whether
or
not
we're
being
clear
enough
about
which
fields
are
exhaustive
or
in
exhaustive.
C
Time,
I
wonder
what
you
can't
I'm
pretty
much
done.
Okay,
thanks
in
sweat,
Google
I
had
two
questions.
One
is
whether
you
considered
using
this
as
a
request
header
as
well,
because
there
are
use
cases
where
you're
an
intermediary
going
back
to
a
back
end,
and
you
want
to
actually
supply
a
different
response
to
the
original
client
based
on
the
client
properties
and
at
least
that's
a
plausible
use
case
worth
considering.
C
C
A
D
T
D
H
A
H
H2,
it's
that
hard,
a
clarifying
question
about
what
API
surface
is
you're
planning
to
have
access
to,
in
particular,
I'm,
assuming
from
the
discussion
so
far
that
you
never
plan
to
pass
this
out
of
the
browser
as
additional
information
into
something
like
an
OS
congestion
controller
or
something
like
that.
You're
just
going
to
use
this
or
the
information
that
browser
needs
for
making
decisions.
It's
not
going
any
lower.
Is
that
right?
No
I!
Don't
think
so!
T
K
P
Hey
so
regarding
that
info,
it
is
currently
as
exposed
the
RTT
and
downlink
like
in
download
speeds
as
the
client
perceives
them,
but
that
is
likely
to
be
something
that
will
go
away
due
to
privacy
considerations,
but
I'm,
not
clear
on
the
youths
case
here.
Are
you
aiming
for
the
proud
to
use
that
information
or
the
client
use
that
information
in
order
to
optimize
something,
or
is
this
something
that
will
be
web
exposed
as
a
JavaScript
API
to
the
actual
application?
P
P
T
A
C
So
I
would
echo
the
privacy
concerned.
I
mean
this
is
not
surprising
and
I.
Think
I
mean
looking
at
that.
I
think
it
was
a
very
serious
thing
to
think
about,
and
maybe
it
kind
of
calls
into
question.
If
this
is
exactly
the
mechanism
you
want
and
maybe
would
be
good
to
like
look
at
what
is
what
is
really
the
problem,
we're
trying
to
solve
and
are
there
other
ways
of
signaling
we
can
do
to
get
that
effect.
C
That's
already
been
brought
up
a
little
bit
because,
for
example,
giving
the
RTT
that
RTT
is
going
to
be
an
estimate
based
on
previous
connectivity,
which
particularly
is
not
going
to
be
very
rich
at
the
beginning
of
a
set
of
connections
and
then
later
on
will
indicate
the
past
and
not
necessarily
what
is
going
to
be
coming
up
hmmm.
Perhaps
what
we
could
do
and
I'd
love
to
understand
the
use
case
more
is
have
indications
from
the
server
saying
hey.
C
It
looks
like
I'm
having
trouble
getting
stuff
back
to
you
at
the
rates
I
would
like
to,
and
if
you,
as
the
client
are
not
adapting
to
that,
it's
a
hint
almost
from
the
server
to
the
client
say.
Maybe
you
should
back
off
or
something
so,
if
maybe
find
a
way
to
make
this
explicit,
rather
than
relying
on
lower
level
measurements
that
may
not
really
map
well
onto
the
semantics
of
HTTP
would
be
more
effective.
In
this
case,.
C
C
T
L
Ahead,
this
is
just
an
observation.
This
seems
like
the
kind
of
thing
that
would
fit
in
well
with
I'm
sending
headers
any
point
within
a
request
for
response.
So
what
do
you
expect
to
be
able
to
send
multiple
of
these
response?
If
that
was
technically
possible?
Yeah
assumes
oh
yeah,
and
on
that
note,
the
the
issue
that
Roy
created
Piatra
provided
a
link
to
something
called
a
metadata
frame.
That
could
also
refer
to
the
connection,
but
carry
a
header
like
that.
So
you
could
get
connection
level
statistics
rather
than
just
connection
level.
D
V
V
It's
an
API
to
provide
server
timing,
information,
not
terribly
unlike
this,
so
you
might
look
at
that
see.
Wind
is
probably
not
what
you
want.
That's
gonna
vary
between
congestion
control,
algorithms
like
how
to
interpret
that
like
that
means,
maybe
a
slightly
different
thing
like
in
bbr
than
it
does
in
Reno,
and
that
kind
of
thing
you
might
be
more
interested
in
delivery
rate
and
that
kind
of
thing
is
a
bandwidth.
F
V
T
There's
other
values
in
there
that
might
be
might
be
helpful
for
this,
like
we
also
include.
So
all
of
the
fields
were
the
exception
of
are
the
the
first,
the
first
value,
so
the
the
name
of
where
this
is
coming
from
and
the
time
everything
else
is
completely
optional,
and
some
of
the
other
values
include
what
congestion
control
algorithms.
Are
you
using
PBR
using
something
else?
If
you
have
a
look
at
most
of
the
values
inside.
V
Of
one
of
these
we've
learned
like
in
HTTP,
is
you
want
to
concentrate
on
the
semantics
rather
than
the
the
really
instance
of
that
right?
So
you
don't
want
to
say
it's
PBR
and
it's
Seawind
and
you
figure
that
I.
Don't
you
want
that?
What's
this,
what's
the
Mantic
of
how
much
bandwidth
do
I
have
that's
like
kind
of
the
usual
way?
What
is
TS
mean
it's
the
timestamp,
but
what
is
it
time
sniffing?
That's.
T
C
A
T
A
R
R
N
Figured
that's
where
you'd
want,
so
this
is
the
idea
of
defining
an
extension
to
htv-2
and
eventually
quick.
That
would
allow
us
to
send
metadata
midstream
in
a
request
to
a
response,
and
so
I
describe
what
I
meant
by
that
in
the
issue
which
I'll
skip
ahead
and,
and
we
look
down
below
use
cases,
there's
a
number
of
different
things
that
we
could
use
this
for.
N
But
you
don't
want
to
set
it
in
front
of
the
body
because
you
don't
want
to
you,
don't
want
the
time
we
don't
want
the
user
performance
to
suffer
because
of
all
the
metadata
you're
sending
in
front,
so
you
send
it
after
you
sent
most
of
the
body.
That's
very.
It
was
a
critical
problem
with
the
alternates
header
field
when
it
was
defined
for
reactive
content
negotiation.
It
was
just
too
big
and
it's
also
useful
things
like
link
preload
we'd
send
that
information
after
you
figured
out.
Oh
hey.
N
Performing
against
your
site,
you
can
use
those
algorithms
to
anticipate
you
might
want
to
push
to
the
client
or
what
they
might
want
to
pull
ahead
of
time,
and
these
are
our
algorithms
that
aren't
necessarily
going
to
complete
before
you
send
the
header
fields.
So
you
might
want
to
send
the
result
of
that
in
the
in
body.
Things
like
that
and
long
pole,
things
that
aren't
related
to
a
separate
channel.
Those
are
all
use
cases
so,
as
it
turns
out,
we
I
I,
put
this
on
the
list.
N
A
So
Roy,
just
one
clarification
when
I
set
up
in
an
issue
I
did
mean
encore.
Oh,
you
did
yeah,
because
I
think
the
important
thing
to
clarify
is
right.
Now
in
core
we
say
that
the
the
abstract
model
of
HTTP
is,
you
have
headers,
and
then
you
have
body
and
then
you
have
trailers
and
we
need
a
clarification
that
trailers
might
come
early.
C
Should
talk
about
that?
Okay,
good
Ian,
sweat,
Google,
I'm,
fairly
sure,
I,
know
the
authors
of
this
extremely
well
also
I
think
it
turns
out
that
in
our
implementation
we
support
this
already
well
in
the
in
the
moat.
If
we
support
trailers,
we
support
it,
I
think
the
people
who
implemented
our
hb2
implementation
actually
thought
this
was
allowed,
even
though
they
thought
it
was
completely
bizarre
and
then
the
last
thing
was
a
they
I
would
recommend.
We
call
these
Midler's,
because
the
bats
are
so
much
fun.
C
N
One
is:
is
HV
two,
given
the
progress
they've
made
it
I'm
this.
This
particular
issue
is
for
h-e-b
two
there's
another
one
for
quick
which
doesn't
have
any
of
this
discussion
on
it,
but
as
referenced
from
this
issue.
So
so
it's
but
not
for
h1,
because
I
tried
to
do
that
in
h1,
and
it's
too
painful
I.
W
Do
they
when
they
are
forwarded,
do
they
have
to
be
forwarded?
Do
they
have
to
be
in
the
same
location
when
they
are
for
it
when
we're
doing
HTTP,
3
or
a
quick
version
to
this
doing
partial
reliability?
Are
these
about
the
stream
or
within
this
dream
becomes
a
really
interesting
fun
question.
So
these
are
the
things
that
I'm
a
little
worried
about
with
with
regards
to
this,
because
it
could
be
fantastically
under
spective.
We
don't
think
about
that.
So.
W
O
K
E
Hawk,
lastly,
I
think
this
is
very
useful
for
service
training
traders
mid
response.
On
the
other
hand,
I
actually
wonder
if
this
would
be
useful
for
sending
priority
updates
will
be
calls
priority,
updates
I
expect
it
to
be
sent
after
the
client
closes
their
quest
and
it
could
arrive
after
the
server
has
completely
sent
a
response.
So
if
we
are
going
to
use
that
it
means
that
the
server
needs
to
retain
the
connection
assets,
dream
state
forever,
so
I'm
not
sure
to.
G
Yeah
mum
times
and
I
think
that's
fine
and
priority
would
be,
would
fall
into
that
class,
but
I
think
because
always
point
in
and
particularly
applies
to.
Something
like
quick
is,
if
you
put
this
in
the
middle
of
the
request
stream,
the
request
stream
is
long
gone
by
the
time
that
you
need
to
have
that
information
updated.
So
it's
not
going
to
be
useful
for
priority.
I
gotta
play.
G
Stream
sort
of
store
is
there,
but
in
in
quick
it
wouldn't
I
got
to
basically
say
camping.
A
new
frame,
type
and
HVAC
know
is
so
there's
gonna,
be
a
different
spelling
of
this
I
think
if
we,
if
we
want
to
pursue
this,
at
least
that
would
be
my
preference
I
can
see
how
this
had
helped.
The
decisions
that
led
to
this
are
all
rational
and
perfectly
reasonable,
but
I
think
there's
a
different
spelling
of
this.
That
would
be
a
little
better,
particularly
the
the
compression
thing.
G
G
N
Believe
Julian,
it's
it's
under
I
under
restricted
to
IETF
review,
so
basically
the
the
actual
assignment
would
have
to
be
a
completed
document
from
the
IETF
I'm.
Just
it's
I
mentioned
that
just
because
I
think
it's
kind
of
funny.
Whenever
somebody
just
ignores
the
actual
process,
it
goes
ahead
and
assigns
the
next
unassigned
standard
number,
because
it
happens
all
the
time,
no
matter
what
the
idea
says.
It
happens
all
the
time
we.
A
A
X
A
I
am
really
scared
if
we
introduce
a
new
thing
that
is
not
like
trailers.
It's
gonna
destroy
both
the
new
thing
and
the
old
thing,
because
most
developers
aren't
going
to
get
it
and
it's
gonna
get
miss
implemented
and
it's
not
going
to
be
available
in
a
backwards
compatible
fashion.
So
I'm
fine,
if
this
is
just
basically
trailers
that
happen
to
arrive
early
and
as
long
as
you
can
treat
them
like
that,
and
they
work
within
those
constraints.
That's
I
think
pretty
tractable.
A
Q
N
Q
W
N
J
Mike
Bishop
I
will
I
will
say
that
I
don't
really
have
a
problem
with
trailers
that
arrive
or
early
I.
Think
the
more
challenging
thing
is
going
to
be
the
fact
that
you
then
might
also
have
trailers
that
arrive
at
the
normal
time.
And
what
do
you
do
with
more
than
one
set
of
trailers
or
potentially
lots
of
sets
of
trailers
over
the
course
of
an
issue
be
message.
L
Party
I
think
how's.
It
related
to
that
and-
and
there's
probably
already
an
answer
to
this,
but
I
really
wonder
how
this
gets
exposed
to
something
like
fetch
in
in
like
if
I
don't
know
when,
when
that
set,
will
be
bounded
and
finished
like
how.
How
much
time
do
I
keep
waiting
to
process
a
headers
object
and
the
implications
of
that
so
I
think
we
should
think
about
that.
While
we
Transpac
something
that
because
user
agents
are
all
the
same,
but
they
have
different
api's
yeah.
N
I
I
agree
with
that
Lucas
and
that
one
of
the
reasons
why
we
were
why
we
went
through
all
of
the
trailer
specs
moved
into
semantics
and
and
and
just
defined
it.
The
way
we
did
was
to
correspond
to
some
of
the
feedback
that
we
got
from
Anna
about
from
fetch
that
he
actually
wanted
it
to
be
in
separate
trailers,
separate
trailers
from
header
fields.
So
you
have
you
have
header
fields
that
you
know
up
front.
Then
you
have
trailer
fields
that
you
don't
know
up
front
and
to
not
mix
those
two.
N
The
way
we
had
described
before
for
HB
one
and
as
painful
as
it
is
to
go
back
and
just
revisit
that
decision.
The
reality
is
the
way
he
described
as
it's
easier
for
people
to
implement
now
and
less
security
issues.
So
we
actually
went
ahead
and
made
that
change
and
I
think
hopefully
the
same
way.
Anna
will
look
at
this
and
and
be
able
to
come
up
with
a
reasonable
design
or
someone
to
do
that.
I'm,
certainly
not
gonna.
Try
to
design
the
browser
side
for
them.
Okay,.
L
I'd
say
the
reason
I
ask
is
because
fetch
isn't
just
within
the
browser
context,
but
is
used
in
in
other
places.
It's.
W
A
A
Not
where
the
work
is
I
want
to
check.
Well,
I
think
we
can
be
more
clear
in
core
but
yeah,
okay,
good
yeah
and
then
in
that,
but
it
would
be
an
H
to
an
extension,
maybe
niche
three
extension
blah
blah,
yeah,
okay,
okay,
I
think!
That's
all
we
have
I
think
so.
I
mean
it
sorry.
One
thing
I
in
when
I
was
up
at
the
mic:
I
used
the
phrase
Trail
of
Tears
and
I
did
that
unintentionally.