►
From YouTube: IETF105-HTTPBIS-20190725-1550
Description
HTTPBIS meeting session at IETF105
2019/07/25 1550
https://datatracker.ietf.org/meeting/105/proceedings/
B
A
Cool
right,
you're,
a
little
on
the
loud
side,
just
say
no
I
mean
specifically
now:
okay,
let's
go
ahead
and
get
started.
It
is
a
very
thin
crowd
today,
which
maybe
will
make
it
productive.
We'll
see
this
is
HTTP.
This
is
the
note.
Well,
if
you're
not
familiar
with
it,
please
search
for
it
on
your
favorite
search
engine
on
the
Internet.
A
A
E
D
E
F
A
A
A
So
we're
gonna
talk
about
that.
Hopefully,
for
about
15
minutes,
we
don't
want
to
take
too
much
time.
Then
we
have
a
quick
presentation
on
HTTP
s:
sv
h,
vs
SVC,
which
I
see
I
forgot
an
s
and
hopefully
that'll
be
relatively
brief.
Then
we'll
go
through
the
core
issues
as
much
as
we
can
time
permitting.
We
have
a
presentation
on
braid
any
bashing
of
the
agenda.
A
G
H
There
tigrin
Akamai
I'm
gonna
be
talking
about
a
HTTP
SVC
DNS
record
Untied,
which
hopefully,
this
will
probably
not
be
the
actual
end
name
of
that
of
the
record,
as
if
only
given
this
year,
number
of
typos
we've
seen,
including
my
own
on
the
on
how
many
asses
it
has
on
next
slide.
So
the
motivation
for
this
has
come
out
of
trying
to
solve
a
bunch
of
problems
holistically
that
have
each
been
popping
up
in
various
places.
Independent
live
each
other
there's
been
kind
of
a
long-standing
kind
of
issue
or
question
is,
is
hey?
H
Wouldn't
it
be
great
if
there
was
something
that
was
SRV
like
or
HTTP
record
like
or
similar,
that
that
HTTP
clients
would
use,
and
but
as
a
number
of
thing,
as
we've
been
as
HTTP,
3
kids
coming
into
play
and
is
encrypted,
S&I
is
coming
into
play
and
as
people
on
the
dns
side
are
getting
more
and
more
frustrated
about
the
zone.
Apex
problem
there's
starting
to
build
a
critical
mass
of
pressure
to
actually
try
to
solve
this
problem.
So
this
record
is
trying
to
look
at.
How
do
we
solve
a
number
of
these
problems?
H
So
the
idea
would
be
to
have
a
single
new
records
that
clients
could
resolve
in
parallel
with
a
and
quad-a
lookups
note,
this
is
client
specific,
not
browser
specific.
Despite
what
the
my
typos
on
the
first
version
of
the
slide
I
had
trying
to
design
something
that
is,
that
usable
and
fits
well
into
the
into
the
way
that
people
configure
configure
HTTP
available
services
having
it
be
extensible
enough,
so
that
when
we
come
up
with
the
next
sort
of
use
case,
we
want
to
solve,
it
doesn't
become
a
oh.
H
No,
but
now
we
need
to
get
clients
to
go
and
do
yet
another
lookup.
But
it
is
something
that
we
can
extend
onto
this
and
also
something
on
something.
That's
compelling
enough
and
solves
enough
of
the
problems
that
we
can
convince
clients
to
actually
go
and
implement
it
as
well
as
looking
at
this,
as
is
it
an
opportunity.
Are
there
opportunities
here
to
move
to
more
secure
defaults,
for
example,
now
that
the
v-world
is
gone
from
being
mostly
HTTP
to
mostly
HTTP
has
seen,
at
least
from
the
perspective
of
a
browser
perspective?
H
So
the
general
approach
here
ends
up
looking
very
similar
to
SRV
if
you're
familiar
with
SRV
familiar
with
SRV,
but
but
with
the
ability
to
add
more
extensibility
on
to
it
so,
for
example,
being
able
to
for
host
name
such
as
dub
dub
dub
example.
Comm
say
that
there
there
may
be
two
different
services
that
could
that
can
implement
this.
H
For
you,
one
of
them
is
that
at
a
at
service
domain
name
one
and
has
this
set
of
IPs
and
on
this
court
and
implements
HTTP
3
on
and
as
this
encrypted
us
a
Nike,
and
this
other
implement,
instantiation
or
implementation
of
the
service
might
have
a
different
domain
name.
A
different
set
of
ports,
a
different
set
of
application
protocol,
calls
and
a
different
ES
and
Ikey
next
slide.
H
I
mean
there
are
two
forms
of
this,
one
of
which
is
a
alias
form.
That's
really
meant
to
delegate
over
Authority.
Its
primary
purpose
is
to
solve
this
zone
apex
problem
of
the
fact
that
you
that,
for
a
hostname
like
example.com,
you
can't
put
us.
You
can't
put
a
cname
note
that
the
intent
kind
of
a
compromise
here
is
that,
for
there
are
two
places
you
can,
you
can
have
HTTP
service
record,
one
of
which
is
for
things
that
are
standard,
HTTP,
4,
4,
4,
4,
3,
you
or
eyes.
I
H
We
have
not
defined
yet
for
alternative
service,
but
if
we
were
to
define
something
other
than
HTTP
or
HTTPS,
we
wanted
to
do
alternate
service
way.
Okay,
you
could
use
that
for
trying
to
think
ahead
a
little
bit,
but
the
and
then
the
second
form
is
an
alternative.
Is
the
is
the
alternative
services
form
and
this
you
can
kind
of
is
a
one
that
looks
much
closer
to
a
like:
SRV,
that's
extensible.
H
So
in
this
you
have
a
there's
a
a
priority.
The
priority
is
there
because
there
is
no
within
our
sets.
You
don't
have
an
ordering.
So
if
you
want
to
have
a
explicit
ordering,
you
need
to
have
a
priority
to
specify
what
that
ordering
is
like
and
then
the
rest
of
it
is
actually
taking
the
the
alternate
services
concept
that
we've
that
we've
defined
that
we've
defined
for
HTTP
and
having
a
way
to
have
that
in
DNS,
there's
a
remit
from
the
perspective
or
from
feedback
we
had
in
DNS
up.
H
As
a
within
the
context
of
the
draft,
the
current
draft
defines
a
yes
and
I
keys.
Alt
service
parameter
extension,
it
that
might
be
something
that
actually
wants
to
be
split
off,
could
set
its
own
draft,
but
at
least
for
now
it's
for
simplicity
is
just
incorporated
directly
here.
The
next
slide,
so
some
of
the
major
feedback
we've
gotten
on
this
so
far,
we've
come
brought
this
to
DNS.
H
Often
the
TLS
working
group
and
have
had
a
bunch
of
hallway
conversations
is
how
much
to
generalize
this
I
think
there's
there's
interest
in
having
it
more
general
than
just
HTTP.
There
is
so,
for
example,
at
least
generalizing
it
to
be
kind
of
an
alt
service
level
of
generalization,
I.
Think
there's
a
question
of
just
generalizing
it
much
beyond
that
start.
Opening
up
the
Pandora's
box
of
or
overgeneralization
go
create
your
own
working
groups
then
years
on
it
and
has
something
no
one
uses
but
I
think
there's.
H
H
Another
one
is
whether
to
allow
external
references
to
named
keys
like
for
the
es
and
I
keys.
You
may
have
a
number
of
different
records
here
that
all
have
the
same
key
and
having
to
have
that
same
value.
Over
and
over
again,
it
starts
getting
fairly
big
but
in
the
same
time,
there's
a
there's
performance
that
impacts.
If
it's
not,
if
you
don't
have
any
cash
difficult
fetch
it
again,
there
is
a
I
think
the
impact
on
climb
complexity,
especially
for
non
browser
clients.
H
H
This
is
yet
another
hurdle
that
things
might
have
need
to
jump
over,
and
another
thing
we've
gone
from
some
client
implementers
is
whether
they
would
whether
in
their
implementations,
they
would
require
on
the
use
of
doe
or
DNS
SEC,
if
only
as
a
both
from
a
what
is
kind
of
the
risk
exposure
of
having
this
in
unauthenticated,
but
also
from
the
how
much
does
doing
yet.
Another
record
lookup
through
poorly
implemented
home
home
router
resolvers
caused
problems
next
slide,
I.
H
H
H
Kind
of
like
be
it
the
next
slide.
So
in
terms
of
next
steps
here
we
presented
this
to
DNS
op.
There
was
there
was
interest
there
actually
interests.
The
degree
that
both
by
nine
did
an
implementation
before
I'd
even
presented
here,
and
then
someone
from
unbounded
in
implementation
during
the
during
the
hackathon.
H
There
haven't
yet
been
any
client-side,
implementations,
I,
think,
there's
a
question
and
a
discussion
between
the
or
there
was
going
to
be
a
discussion
between
the
DNS
options
in
the
HTTP
chairs,
as
to
which
working
group
makes
more
sense,
I
think
the
degree
to
which
we
generalize
that
will
make
a
impact
on
this
I
get.
We
if
gave
you
in
some
of
the
maybe
we
should
generalize
this
just
feedback.
H
It
may
end
up
being
that
pushing
the
DNS
direction
makes
sense
with
close
consultation
here
on,
we
gave
some
visibility
to
TLS
working
group,
because
I
think
there
would
be.
It
would
be
very
nice
to
not
have
to
have
a
special,
yes
and
I
record
that
contains
a
to
the
contains
IP
addresses
and
other
stuff
and
a
special
purpose
for
that.
H
F
H
In
Hawaii,
it
may
even
call
be,
and
then
Mike
had
one
that
was
called
had
a
alt
service
where
Mike
had
been
had
the
alt
service,
one
that
a
lot
of
this
is
derived
from,
but
this
is
each
one
of
these.
Variations
of
this
is
taking
a
lot
of
the
feedback
and
refining
it
to
try
to
kind
of
address
this
thing.
The
issues
that
came
up
previously.
A
H
A
Previously,
you
know
a
lot
of
concerns
that
I
heard,
or
that
I
remember
at
least
were
around
authentication
and
integrity,
the
information
and
also
a
concerns
around
clients
making
a
lot
of
parallel
requests
and
how
difficult
that
can
be
now
with
no
and
with
the
increased
deployment
of
DNS
SEC.
That's,
maybe
a
change
situation
right.
H
That
was
a
changed
situation.
I
think
it's
also
the
the
yes
and
Ike
he's
one
is
one:
that's
pushed
it
because
it
some
point
that
is
forcing
clients
to
make
another
request.
So
I
think
that
was
the
thing
for
me.
That
said,
okay,
if
we're
gonna,
if
we
can
have
to
do
that
extra
request
there
can
we
can
we
solve
a
bunch
of
the
other
problems
that
we've
been
saying.
Hey
would
be
nice
if
we
could
get
clients
do
another
extra
request,
but
then
look
at
how
do
we
do
that
right?
A
J
Then
Schwartz
I,
just
want
to
on
the
topic
of
authentication
I,
want
to
point
out
that
this
draft
is
intended
to
be
used
and
it's
fully
usable
on
authenticated
and
to
some
extent,
I.
Think
that
previous
concerns
about
authentication
of
this
kind
of
information,
I
think
have
decreased,
because
the
TLS
working
group
has
had
to
think
through
very
carefully
the
consequences
of
distributing
yes
and
I
unauthenticated
and
and
confirmed
with
everything.
K
So
to
to
comment
someone
hair
check,
yeah
chair,
had
completely
off
as
a
client,
implementer
I
think
we
are
interested
in
taking
advantage
of
something
that
looks
like
this
and
see
how
it
develops
so.
I
think
there's
interest
there,
but
then,
as
a
with
chair
head
on
I,
did
have
a
discussion
with
Ben
Oh
who's,
one
of
the
Denisof
chairs
earlier,
so
just
for
this
room,
I
think
his
sense
of
their
room
is
that
they
are
very
interested
in
doing
this
work
and
moving
that
work
there.
K
K
L
Yeah
so
Mon
Thompson
again
as
a
client
in
home
and
work
had
some
discussions
about
about
this
and
a
reasonably
enthusiastic
about
something
that
might
stand
in
for
es
ni.
That
is
a
little
less
janky
than
the
current
record
format,
certainly
having
the
enthusiasm
of
the
DNS
community,
or
at
least
people
who
know
what
they're
doing
makes
us
a
little
happier
about
this
sort
of
thing.
And
if
we're
going
to
be
making
extra
queries
for
different
record
types,
it
may
as
well
be
a
good
one.
So
tentatively
positive
on
this
one.
H
N
Meant
in
terms
of
which
working
group
that
lives
in
DNS
off
already
did
something
like
this
and
it
was
called
SRV
and
the
buddy
and
the
chief
he
has
touched
it
so,
no
matter
where
it
lives.
We
have
to
have
buy-in
from
this
working
group
and
from
the
implementers
here
or
we
just
shouldn't,
do
it
mm-hmm
I,
don't
care
who
works
on
that?
We
should
all
work
on
that,
but
the
interest
has
to
be
here.
H
And
one
of
the
bility
some
of
this
depends
on
what
is
the
right
factoring
in
terms
of
how
general
could
be
a
a
into
these.
The
general
purpose
draft
that
describes
how
to
use
it
and
then
one
that's
Indiana
soft
and
then
a
specific
here's
how
to
use
this
for
HTTP.
That
covers
some
of
the
HTTP
specific
things
like.
How
does
this
work
in
the
case
of
proxies
and
other
things
that
might
live
here.
O
Potentially
interesting
complexity,
here
is
what
happens
when
you're
using
DOE,
and
maybe
it
does
another
DNS
server
simultaneously.
The
great
thing
about
DOE
is
like
the
rest
of
HTTP.
It
can
be
per
session,
but
the
other
DNS
servers
may
be
different,
and
so
you
can
end
up
with
weird
bounces
I
think
you
have
to
resolve
that
one
way
or
another,
and
it
would
be
really
weird
and.
P
Also,
this
we've
got
the
feedback
that
that
runs
a
risk
of
bloating
those
records
and
people.
Weren't
super
excited
about
that.
So,
generally,
I
would
love
to
see
some
solution
that
resolves
the
early
content
negotiation
problem
while
not
introducing
that
bloated
DNS.
Maybe
it
can
be
in
collaboration
with
this
and
other
layers
or.
L
Yeah
Thompson
I
want
a
pony
too.
Unfortunately,
if
you,
if
you
want
some
sort
of
bootstrapping
here,
you're
gonna
have
to
pay
some
price.
We've
found
that
particularly
with
things
like
like,
though
the
the
the
additional
cost
is
relatively
modest
in
terms
of
performance,
the
is
my
record
store,
finding
a
packet,
basically
that
wouldn't
fit
in
the
typical
UDP
packet.
L
Quite
so
much,
but
probably
that's
probably
just
reflecting
my
misunderstanding
of
hello
Dennis
over
UDP
works,
but
I
think
this
is
really
kind
of
valuable
I
think
this
is
more
valuable
as
a
this
is
a
TLS
record
and
you
have
in
that
TLS
record.
You
say:
here's
where
you
go
to
connect
to
them
is
here's.
L
Maybe
the
port
number
I,
don't
know
whether
the
port
number
makes
any
sense
in
this
context,
and
here's
all
the
bootstrapping
information
in
here
3s,
9
and
I'm,
almost
at
the
opinion
that
if
this
doesn't
always
include
ears,
ears
and
I,
it's
not
really
doing
us
very
much.
Good
I
would
like
to
have
some
always
be
SMI.
L
A
A
Sorry
then,
I'd
mentally
inserted
myself
and
cue,
if
you
don't
terribly
mind,
I'm
lazy
personally,
no
hats
I
think.
The
reason
why
I
wanted
to
follow
Martin
was
that
there's
a
little
bit
of
tension
there
in
that
some
people
are
seeing
this
as
a
generic
TLS
mechanism.
I
see
it
more
as
a
generic
mechanism
that
it
has
a
lot
of
benefits
if
it's
aligned
with
alt
services,
which
means
it's
HTTP,
specific,
potentially
and
and
I-
think
we
lose
something
if
it
were
if
that
were
taken
out.
J
Q
A
A
So
there's
been
a
discussion
in
the
quick
working
group
about
priorities
and
I
think
there
are
several
proposals
floating
around,
but
the
the
point
we
came
to
was
that
the
decision
about
the
future
priorities
needs
to
come
mostly
from
this
community.
Since
you
know
the
charter
of
quick
is
to
reflect
the
semantics
of
http/2
and
that
lives
firmly
here
and
so
the
question
is,
you
know,
there's
a
lot
of
backstory
here:
we're
not
going
to
go
over
it
now,
because
I
think
most
people
are
familiar
with
it.
A
There
is
a
lot
of
doubt
about
the
utility
of
priorities
and
http2,
let
alone
hp3.
There
are
a
lot
of
quick
implementers,
so
you
don't
want
to
include
http/2
priorities
in
htv3
at
all,
and
so
as
a
community
here
they'd
like
our
advice
as
to
whether
we
want
to
hold
them
to
that
bar
of
including
htv-2
priorities
in
htv-3,
and
so
that's
in
some
ways,
a
yes
or
no
question.
A
There
are
a
lot
of
other
questions
to
ask
in
a
lot
of
different
ways
to
get
where
we
to
it
to
a
place
where
we
have
better
priorities
in
HTP
and
by
the
way,
every
time
I
say
of
priorities.
What
I
really
mean
is
client-to-server
hints
about
priority
when
they're
sending
responses,
because
that
seems
to
be
continually
in
effect,
I've
gotten
these
discussions,
it's
a
horrible
name,
so
cue,
the
mics,
let's
figure
this
out,
can
we
prioritize
the
nevermind.
E
J
J
O
A
O
Can
you
please
slow
down?
I
can't
understand
you.
Sorry
I
was
trying
to
go
slower
anyway.
Okay
prioritization
is
difficult
and
arguably
and
could
be
complete,
so
it
will
always
be
suboptimal,
particularly
if
one
endpoint
operates
in
ignorance
of
the
needs
of
its
peer
HGB
to
implement
introduced
a
complex,
prioritization
signalling
scheme
that
used
a
combination
of
dependencies
and
weights
formed
into
an
unbalanced
tree.
That
scheme
also
depends
on
in
order
delivery,
so
it
is
unsuitable
for
use
in
protocols
like
HTTP
3,
which
attempt
to
avoid
global
ordering.
O
Furthermore,
though,
that
scheme
was
rich
in
some
ways.
It
has
proven
to
be
inadequate
in
several
others.
It
is
not
well-suited
to
major
use
cases
like
live
video
delivery,
and
it
cannot
be
used
to
carry
hints
from
servers.
This
prioritization
scheme
also
suffered
from
poor
deployment
in
Interop.
Most
server
implementations
do
not
include
support
for
the
scheme.
Unfortunately,
I
know
somebody
who
actually
did
all
of
it
is
awesome
by
the
way
Alan
some
favoring
bespoke
schemes
instead
based
on
heuristics
and
other
hints,
like
the
content
type
and
the
order
in
which
the
requests
arrive.
O
Retaining
the
h2
priority
scheme
increases
the
complexity
of
the
entire
system,
and
we
don't
have
evidence
that
this
complexity
is
offset
by
any
value,
and
then
we
have
a
little
draft
here.
That
says
we
should
you
know
deprecated
them
and
basically
that
you
know
servers
shouldn't
necessarily
respond
to
them
after
we
submit
this
and
the
clients
shouldn't
send
them,
and
we
also
need
something
better,
probably
but
sure.
L
So
month,
also,
this
is
the
essence
of
the
discussion.
We're
having
I,
don't
think
many
people
are
particularly
attached
to
the
HTTP
to
scheme,
which
is
part
of
the
reason
we
put
this
in
place
and
copying.
Something
we
know
is
for
one
of
a
bit
of
work.
Bad
into
a
new
protocols
would
be
irresponsible.
L
L
Without
incredible
effort,
now,
if
that
happens
and
I
I
will
help
drive
that
but
I
don't
think
we're
going
to
succeed.
But
I
will,
if
that
happens,
we
can
put
that
priority
scheme
into
both
HTTP
2
and
HTTP
3
and
and
single
happy
dancing
and
celebrate
victory,
but
I
think
we're
looking
at
shipping
quick
within
sort
of
six
months.
Ish
and
six
months
is,
in
my
experience,
not
enough
time
to
decide
on
like
the
color
of
wallpaper,
let
alone
something
as
complex
as
a
prioritization
scheme.
So
Martin
before.
A
L
Position
on
this
might
be:
if
the
community
decides
that
we're
gonna
bend,
we're
going
to
just
abandon
this
scheme
and
we're
gonna
go
searching
for
another
one.
We
will
join
that
community
and
abandon
this
game
and
go
searching
for
another
one,
and
that
means
potentially
doing
things
like
experimenting.
L
We
have
a
team,
that's
dedicated
to
looking
at
performance
of
base
loading,
and
there
they've
done
some
really
deep
analysis
on
what
on
what
needs
to
happen
and
they're
just
now,
looking
at
how
they
might
signal
that,
and
so
we're
at
a
point
where
we
do
have
the
opportunity
to
to
run
those
sorts
of
experiments
right.
So
I
think
we're
pretty
well
positioned
to
to
be
participate
in
this
in
this
effort.
If
people
are
interested
in
doing
it
so.
L
N
Rick
bishop,
so
in
the
side
meeting
we
discussed
a
couple
of
different
paths
from
where
we
are
to
happy
State.
One
possibility
was
having
an
extension
that
let
you
negotiate
potentially
multiple
priorities
schemes,
but
at
the
minimum
we
will
have
nothing
h2
and
whatever
we
come
up
with
probably
some
other
experiments
on
the
way
and,
of
course,
the
problem
with
having
a
flexible
negotiation
scheme
like
that
is
that
you
could
have
total
mismatch
between
what
the
client
and
server
support,
and
there
was
a
lot
of
concern
about
going
there
potentially.
N
But
what
I
think
there
was
general
agreement
on
is
following
on
from
that
draft,
having
an
extension
in
h2
to
say:
hey,
I,
don't
support
priorities,
don't
bother,
send
them
to
me
or,
conversely,
as
the
client
I'm
not
going
to
send
you
priority.
Is
that
there's
not
a
request
for
equally?
We
did
that.
That
is
a
use.
N
Your
best
judgment
so
I
think
probably
the
first
step
for
this
working
group
is
adopting
the
extension
of
that
of
that
sort,
potentially
in
parallel
with
saying
we've
deprecated
this
and
the
setting
indicates
that
you
are
a
client
aware
of
that
declaration
and
then
h3.
That
would
just
be
the
normal
state
and
we
could
rip
it
out
of
each
three
entirely
or
maybe
there's
a
reverse
to
say
they
actually
do
support
this.
A
N
G
That,
of
course
creates
this
sort
of
paradox
on
the
client
about
whether
it
should
issue
a
request
now
or
whether
it
should
wait
in
order
to
determine
what
might
want
to
go
before
this
request
right
intrigues
idle
time
on
the
wire
and
idle
responses.
If
you
do
it
in
one
direction
and
then,
if
you
do
it
in
the
more
aggressive
direction,
they
result
in
your
higher
priority
content,
getting
pushed
out
by
other
things
and
I
think
we.
We
learned
that
as
a
key
objective.
G
Get
any
consistency
between
implementations
when
using
in
and
no
one
wants
to
implement
it
going
forward,
and
we
would
be
foolish
to
ignore
you
know
those
statements,
so
I
think
we
need
to
sir
take
that
as
a
given
with
regard
to
h2
and
the
engines,
we
have
to
find
something
different,
which
kind
of
leads
us
in
the
pool
of
do
we
have
something
different
or
do
we
want
to
go
like
with
nothing
and
I?
Think
my
my
argument
is
rather
than
say
nothing.
G
G
Was
that
would
kind
of
been
kind
of
been
merging
towards
consensus
among
people
most
involved
in
that
direction?
So
that's.
That's
certainly
interesting
input
I'm
wondering
if
we
could
get
consensus
on
something
that
we
knew
was
minimal,
that
in
a
similar
way
to
we
want
to
replace
nothing
with.
The
happy
stage
would
be
interested
in
replacing
minimal
with
a
happy
state
and
there
are
lots
of
minimal
solutions
that
have
been
used
in
many
many
domains.
G
So
I
would
like
to
suggest
to
see
if
we
can
call
us
an
idea
like
that
and
make
that
you
know
a
required
part
of
shipping
quick
because
it
could
should
be
simple,
easy
and
small.
Even
if
we
know
it's
not
like
fully
expressive
and
then
in
parallel
or
continum,
the
happy
state
for
lack
of
a
better
term.
P
So
a
couple
of
points,
one
Mike
suggested
that
there's
a
lot
of
fear
from
a
client-server
negotiation
of
the
right
scheme,
which
will
result
in
a
mismatch.
The
result
of
a
mismatch
is
there
is
no
pradhan
priority
scheme,
which
is
effectively
the
current
status
quo
and,
regarding
request
ordering,
we
have
a
bob
in
chrome
that
pre
old
requests
go
out
before
other
low
priority.
P
Riddled
requests
go
out
before
high
priority,
for
example,
CSS
requests,
but
like
two
milliseconds
before
them,
just
because
of
a
bug
that
effectively
results
in
those
low
priority
images
arriving
to
the
client
before
the
CSS,
because
they
went
out
two
milliseconds
earlier.
That
is
the
state
of
current
h2
priority
implementations.
So
a
request
order
based
priority
scheme
is
not
going
to
be
significantly
different
than
what
we
see
today
for
many
of
the
implementations,
not
all
of
them.
A
Have
a
very
dated
queue,
so
we
need
to
make
it
brief,
but
I
want
to
remind
people
that
the
big
question
here
is:
what
do
we
want
to
tell
quic
about
HTTP
3?
There
are
many
different
ways
we
can
get
to
fixing
priorities.
That's
we'd
spend
more
the
way
more
than
time.
We
have
today
trying
to
fix
that.
So
we
need
to
focus
on
what
we're
gonna
tell
HTTP
3.
So.
P
T
Alessandro
cadena
CloudFlare,
so
to
answer
Mark's
question
I,
think
that
at
this
point,
removing
priorities
for
HTTP
3
seems
like
the
most
viable
way
forward.
I,
don't
think
people
are
gonna,
implement
the
currents,
keep
going
forward
for
HTTP
3,
but
following
what
patrick
said,
however,
flawed
the
h2
priorities
are
right.
Now
they
do
provide
some
value,
so
I
would
be
wary
of
just
not
doing
them
at
all
decide.
We
would
be
very
interested
in
experimenting
with
new
schemes
with
whatever
client
wants
to
do
it
with
us.
So
being
other
light.
U
On
the
other
hand,
what
I
would
really
like
to
see
is
new
clients
or
existing
clients
are
starting
using
the
priority
frames
of
HTTP
in
a
new
way,
because
I
mean
today
we
can
switch
our
prioritization
scheme
from
HTTP
to
based
approach
to
a
new
absolute
value
based
back
sink,
and
then
we
can
create
a
translation
table
from
the
HTTP
to
sprout
priorities
that
either
Chrome
or
Firefox.
Since
there's
those
three
or
five
bits,
and
it
will
work
fine
and
assuming
that
that
could
also
become
the
norm
for
HTTP
3.
V
Ok,
so
I
agree
that
h2
priorities
are
broken
and
it's
ok
to
not
copy
them
forward
into
HTTP
3
like
we
should
let
them
go
and
I
think
the
idea
of
having
a
setting
that
indicates
that
were
like
Lucas
could
out
to
the
list
like
a
setting
in
h2
that
says
I'm,
yes,
I
am
going
to
send
h2
priority
or
no
I'm
not
going
to
support
priority
I.
Think
that's,
probably
a
good
thing.
V
I'm
really
worried
about
removing
priorities
entirely
from
each
or
I
should
say.
A
prior
client
sent
priority
hinting
scheme
from
h3,
particularly
from
if
we
were
take
it
out
of
the
critical
path
of
shipping
HTTP
3,
then
it
will
sort
of
remove
the
urgency
to
have
the
scheme
developed
and
it
will
languish
much
longer
and
if
we
go
to
a
state
like
Martin
adjusting
where
the
browser
stopped
sending
any
priority
whatsoever,
and
we
shed
page
three
and
there's
no
priority,
then
we're
gonna
be
in
a
bad
state
for
a
long
time.
V
So
I
think
there's
value
in
having
this.
This
client
send
hinting,
and
one
of
the
reasons
is
that
we
don't
currently
implement
like
a
server-side
content
type
based
and
the
word
in
the
side
view
used
was
fragile.
Skiing
for
the
server
to
come
up
with
its
own
priority
and
I'd
I
would
rather
not
go
there
or
force
every
server
developer
to
go.
There.
W
Yes,
but
I
definitely
have
this
list
support
removing
existing
three
prairies
from
from
quick
in
terms
of
moving
for
it.
I
also
intend
to
spend
a
fair
amount
of
time
and
also
development,
work,
I,
start
running
some
different
experiments
and
trying
to
like
figure
out
what
to
do
but
I.
Think
honestly,
like
I,
expect
we're
gonna
end
up
like
we
chrome
are
gonna
end
up
in
the
inferred.
W
S
Lukas
body
clarify
just
to
say
that
yeah
Alan
mentioned
it
Brad
and
I
pushed
a
very
short
draft
earlier
today.
Just
to
give
an
example
of
how
you
might
write
this
extension
to
advertise
that
you
don't
want
to
use
priority
and
if,
if
you
happen
to
send
priority
frames
after
doing
that,
the
other
side
you'd
ignore
them.
It's
it's
not
perfect,
but
it's
it's
basically
the
mechanism
to
do
what
we're
talking
about
about
removing
priorities.
It
doesn't
articulate
the
problem
space
as
well
as
Roberto's
initiation
to
this
session.
S
O
A
bit
of
a
warning
header,
Bourne
priorities,
have
a
lot
of
complexities
and
on
an
end,
this,
but
header
Bourne
priorities
have
a
lot
of
complexities,
especially
involving
caching.
What's
the
priority
that
you
cache
for
a
range
request,
or
when
you
have
multiple
requesters
from
different
applications
and
different
locations
right
being
set
ice,
actually
support
headers
and
I
support
going
down
this
rabbit
hole
because
I
think
that
headers
are
in
the
end
they're
kind
of
the
essence
of
HTTP
right.
O
They
are
HTTP
everywhere.
It
doesn't
matter
how
you
transfer
it.
They're
part
of
the
semantics
of
HTTP
and
I.
Think
one
of
the
failings
we
had
in
h2
was
that
we
made
it
really
difficult
or
even
impossible
for
a
client
to
signal
its
needs
or
preferences
with
regards
to
priority
headers
being
part
of
the
semantics
being
visible
to
all.
Layers
of
the
stack
are
a
good
way
to
do
this,
and
a
funny
thing
about
headers
is
at
least
with
their
compression,
especially
when
you're
not
using
dependencies,
and
you
just
have
relative
few
priorities.
O
It's
actually
more
efficient
on
the
wire,
so
you
know
added
benefit,
so
I
think
we
should
think
through
these
complexities.
I
think
it
belongs
here.
There's
this
is
an
HTTP
problem,
not
even
a
quick
problem
if
we're
going
to
do
it
in
headers,
and
we
have
to
be
very
careful
about
it,
because
there
are
a
lot
of
areas
that
we
touch.
If
we
do
this.
L
Yeah
Thomson
I,
like
some
of
the
things
in
the
designs
that
people
have
proposed
with
head
and
so
I
like
the
fact
that
you
can
get
that
proper
end-to-end
signal
effectively
and
intermediary
system
is
a
nice
benefit
in
both
directions
was
also
a
nice
and
roberto's
write
about
the
caching.
Of
course,
that's
gonna
be
a
little
tricky
to
work
out,
but
I
think
we
can.
L
T
L
G
A
A
A
V
A
V
A
L
A
L
A
O
O
O
A
B
A
L
R
A
L
D
L
L
L
That
said,
that
I
expected
that
quick
will
be
will
be
stable
a
lot
sooner
than
that
yes
and
people
will
be
very
reluctant
to
make
changes.
Even
you
know
we're
moving
to
late
stage
process
for
all
adult
all
the
drivers
now
aren't
we
I
think
we
didn't
decide
that
we
should
have
done.
We
should
have
decided
that
this
week,
but
there's
going
to
be
some
reluctance
to
to
put
anything
in
implementations
in
in
a
short
time.
Yes,
but
we're
gonna
be
shipping
this
stuff
yeah,
and
we
need
to
be
aware
of
that
right.
A
To
wrap
this
discussion
up
because
we're
definitely
over
time
one
more
question
of
the
people
who
put
their
hand
up
for
the
design
team
who
is
willing
to
put
in
the
work
to
lead
it
to
crack
the
whip
and
make
sure
that
actually
gets
moving.
Ian
you've
got
time
to
do
that,
because
it
will
take
some
time.
Okay,
Ian.
Thank
you
very
much.
We'll
talk
about
getting
me
the
resources
you
need
all.
G
I
A
A
A
Okay,
let's
get
through
these
are
the
issues
that
the
editors
thought
might
benefit
from
some
working
group
discussion.
So
let's
just
go
through
and
see
really
I
think
some
of
them
may
be
quite
short,
number
218,
disambiguate,
403
forbidden
so
as
Bourne
asks,
the
interpretation
of
403
forbidden
is
used
in
two
situations
when
the
request
operation
is
forbidden
and
when
the
request
of
operation
is
forbidden
for
the
user
identified,
some
other
words
it's
a
bit
of
an
authentication
failure
almost,
and
he
gives
us
some
text
here.
If
authentication
for
dozens
were
provided.
A
There
are
quests
that
server
considers
an
insufficient
to
grant
access.
The
client
should
not
automatically
repeat
the
request
with
the
same
credentials.
The
fight
may
repeat
the
request
with
new
or
different
credentials
and
there's
a
further
sentence
later
on.
However,
requests
might
be
forbidden
for
reasons
unrelated
with
the
credentials
and,
if
I
scroll
down
a
little
bit
I
think
I
made
a
proposal.
The
phrase
authorizes
the
first
sentence
is
the
rid
of
the
issue
and
2616
used
to
fulfill
it
instead,
and
so,
if
we
go
back
to
that.
A
Down
here,
yeah
this
bit
right
here
so
in
other
words,
refused
to
authorize
it
refreezes
to
fulfill.
It
would
be
that
the
proposed
text
and
then
as
Bourne
replies
with
a
slight
modification
to
that,
but
I
think
it's
it's
relatively
in
the
spirit.
I
wanted
to
bring
this
up
just
to
make
sure
that
people
were
okay
to
switch
back
from
authorize
it
to
fulfill
it
and
to
prod
Roy,
especially
in
Julian,
to
see
if
there
was
a
reason
why
we
changed
that
in
in
this
I.
S
A
L
Tilton,
what
other
things
might
cause
something
to
generate
a
403?
Is
it
the
face
of
the
Moon
or
I'm
asking
seriously,
because
if
this,
if
the
typical
interpretation
of
a
403
is
that
my
credentials
that
the
credentials
that
I
offered
were
insufficient
right,
which
is
one
which
is
number
two,
then
what's
the
semantics
of
the
point
number
one
servers.
X
Q
Authentication
information
can
be
carried
in
ways
other
than
just
the
standard,
HTTP
authentication
token.
So,
for
example,
if
somebody
presents
in
CDN
interconnect,
if
somebody
presents
a
token
that
is
invalid,
we
make
403
of
them
with
a
reason
that
tells
them
what's
wrong
with
their
token.
So
it's
an
authorization
problem
for
that
specific
user,
but
in
a
way
unrelated
to
the
specific
HTTP
header
named
authorization
I,
don't.
A
L
A
L
Okay,
Marvin
Thompson.
My
understanding
on
your
response
here
is
that
there's
a
generic
error
handling
section
in
the
document
that
talks
about
how
you
might
choose
to
recover
from
variations
in
inputs,
and
that
would-
and
this
would
be
covered
under
that
in
terms
of
this
specification.
So
is
it
that's
not
what
I
meant
that.
A
M
Okay,
I
was
reworking
the
light
range
set
and
I
I
know.
I
said
all
right
ranges
that
allows
one
outside
arrangement
and
a
list
of
right
ranges.
Mike
and
lineup
include
white
space.
In
that
case,
I
didn't
think
there
would
be
interoperable,
but
it
turns
out
that
people
actually
do
seem
to
accept
this
in
practice.
So
I
think
we
can
close
this
as
saying
yeah,
baby
working
breakfast.
M
F
A
A
M
M
A
T
A
L
C
A
N
D
A
L
Madan
Thompson
I
wanted
to
caution
on
that.
One
RSC
28:18
is
old,
it
is
very
II,
let
me
say,
shall
we
say
loose
in
its
description
of
how
to
do
name,
validation
and
and
other
such
things,
and
there
may
be
a
desire
on
the
part
of
the
reviewers
of
this
document
to
have
this
updated
to
more
modern
practices
like
such
as
the
ones
that
are
discussed
in
2061
25.
Thank
you.
I
already
knew
that
number,
and
so
there's
a
hazard
here
and
I
I.
L
A
L
L
So
I
understand,
there's
a
little
difficult,
I,
don't
think
it's
particularly
bad
6125
is
a
very
thoroughly
specified
and
I
think
I
might
without
going
through
with
a
fine-tooth
comb.
All
you
need
to
do
is
read
that
document
very
carefully
and
make
sure
that
matches
up
for
practice,
and
so
then
you
can
just
reference
that
for
the
for
all
that
for
pieces
that
deal
with
wild
cards
and
owners.
A
W
Slay
you
I
was
gonna,
say
28:18
needs
to
die
or
burn
so
folding
pieces
and,
of
course,
semantics
right.
The
the
description
of
the
scheme
is
fantastic,
but
very
little
of
28:18
is
salvageable
in
terms
of
reflecting
modern
reality
right,
so
I'm
I'm
in
favor
of
like
there
are
a
few
nuggets
that
I
do
think,
are
applicable
and
probably
should
be
folded
into
for
semantics.
There's
a
lot
of
other
stuff
like
the
upgrade
semantics
and
some
of
this
weird
stuff
that
just
needs
to
die,
and
it
does
not
reflect
reality.
W
L
K
T
A
Q
A
A
A
A
A
A
Okay,
next
up
169,
URI
lengths
and
so
I
noticed
that
in
messaging
we
limit
so
in
the
HTTP
one
expression
of
HTTP.
We
limit
the
length
of
a
URI,
but
we
don't
have
any
limit
abstractly
in
the
semantics
document
of
what
the
minimum
supported.
Url
link
should
be
by
implementations
so
that,
if
you
transit
between
different
versions,
the
protocol,
for
example,
you
know
there
are
no
minimum
supportive
requirements
and
it
seemed
to
me
that
it
would
be
useful
to
do
that.
A
There's
a
long
discussion
here,
I
had
a
modified
proposal
to
very
end,
based
on
that
discussion.
To
add
to
the
semantic
section
text
that
says
it
is
recommended
that
all
HTTP
senders
in
the
recipient
support
at
a
minimum,
HTTP
or
HDS
your
eyes
with
a
length
of
8,000
octet
note
that
this
implies
some
structures
and
unwire
representations.
For
example,
the
request
line
an
HTTP
1.1
will
necessarily
be
larger
in
some
cases.
A
A
Y
L
A
This
we
don't
have
time
for
this
right
now,
but
I
think
we
need
to
make
some
progress
on
this.
One
I
was
looking
for
something
we
can't
do.
Do
we
have
the
brave
folks
in
the
room?
Okay,
hi
prepare
yourselves
we'll
break
in
another
two,
it's
reinvents.
Unless
we
find
something
really
meaty.
Trailers.
A
A
But
I
know
there
was
another
one
that
was
similar,
but
not
the
same
I,
don't
think
so.
The
spec
currently
says
summer
to
recipients
attempt
to
recover
from
location
fields
that
are
not
valid,
UI
references.
This
specification
is
not
mandatory,
defines
its
processing
but
does
not
allow
it
for
the
sake
of
robustness
and
the
proposal
is
to
replace
recipients
with
implementations
or
client
accommodations.
But
beyond
that,
we
would
close
this
with
no
action
and
that
kind
of
thumbs
up
from
Julian.
A
L
I
A
Z
So
I
want
to
give
you
some
updates
on
what's
happened
since
then,
so
we
well
I've.
We've
been
growing
the
group
of
people
interested
in
this
and
that
SEF
on
the
internet
he's
actually
an
expert
in
synchronization
works
on
Google
Wave
and
he
also
wants
to
have
a
standard
protocol,
and
we
went
together
to
this.
D
web
conference
met
a
lot
of
D
web
people,
who
also
want
the
same
thing
and
we've
been
building
that
group.
Also,
we
wrote
an
internet
draft
to
propose
basic
scheme
and
we
got
some
really
good
feedback.
Z
I
want
to
give
special
thanks
to
Austin
Wright,
who
gave
some
good
feedback
and
Martin
Thompson
and
also
Eric
Kinnear
and
the
general
feedback
was.
We
were
missing
a
lot
of
connections
to
existing
HTTP
standards
or
other
standards
in
that
proposal,
and
also
that
the
proposal
itself
seemed
really
big,
but
once
you
read
it,
it
seemed
small
and
I
think
so
we
think
that
you
were
very
right
and
we
actually
in
working
through
the
existing
standards.
We
found
a
smaller
way
to
look
at
it.
X
We
don't
have
a
good
way
to
be
able
to
either
send
incremental
updates
to
say,
hey,
like
let's
say,
data,
the
changes
every
second
or
every
five
seconds
I'm,
either
clients
have
to
poll
every
five
seconds
which
is
inefficient,
so
that's
no
good
and
for
data,
that's
really
big,
let's
say
a
document,
that's
a
megabyte
in
size.
The
only
way
for
clients
to
handle
things
like
that
over
HTTP
today
is
to
repol
and
get
a
new
copy
of
the
document
every
time
the
document
changes.
X
So
we've
been
talking
about
this
and
I
think
there's
a
really
simple
addition
to
HTTP,
which
is
that
so
right
now
we
have
a
semantic
way
to
be
able
to
change
documents,
so
we
can
submit
a
patch
method
which
is
very
rarely
used,
but
we
can
specify
a
except
patch,
and
then
you
can
say
here
is
my
semantic
change.
I
would
like
to
make
to
the
document
the
semantics
on
the
document
side
of
it.
X
You
can
imagine
a
document
as
a
state
machine
and
we
apply
changes,
so
each
patch
or
each
operation
has-
and
we
want
RFC's
for
each
type
and
the
type
says
this
document
with
this
change
results
in
this
new
type.
The
service
says
here
is
a
new
e
tag,
and
so
then
the
client
can
know
what
the
document
has
changed
into
your
notes.
That
already
exists.
X
The
thing
we're
missing
is
a
way
to
read
those
changes,
so
there's
no
current
way
to
be
able
to
subscribe
to
a
document
and
get
a
feed
of
all
of
the
changes
that
are
being
made
to
that
document.
We
have
things
like
event,
sourcing
or
server,
sent
events
and
WebSockets.
So
this
can
be
built
today
very
easily.
X
So
if
my
cash
instead
subscribes
to
my
document,
then
every
time
my
document
changes
I
can
send
to
the
to
the
cache,
because
I
subscribed
the
semantics
very
small
change
and
then
the
cache
can
update
automatically
do
fan-out
to
any
other
clients
that
are
subscribed
or
the
clients
that
are
connecting
normally.
They
can
then
just
request
the
new
document.
The
cache
then
doesn't
like
his
auto
updating
and
auto
invalidating,
which
is
really
nice
property
without
us
needing
to
send
the
whole
document
every
time
it
changes,
and
we
say
this
already.
I
ET
f
je
map.
X
I
cal
there's
a
whole
bunch
of
different
protocols
that
are
missing
this
synchronization
piece
there
trying
to
do
synchronization
or
trying
to
do
subscriptions
on
top
of
HTTP
right
now
and
either
having
to
poll
or
do
web
hooks
or
various
different
things.
That'll
feel
like
awful
hacks
in
my
opinion,
so
yeah
so
I'm
planning
on
writing
up
an
RFC
for
the
next
one
of
it.
You
know
in
time
for
Singapore
for
sure,
basically
suggesting
that
we
add
a
new
subscribed
method
to
HTTP.
X
That's
gonna
give
us
a
semantic
list
of
changes
but
yeah,
if
that's
exciting,
for
anyone
else
feel
free
to
come
and
talk
to
us,
because
we
want
more
people
interested
in
this
and
there's
some
other
things.
On
top
of
that
that
we
might
be
able
to
do
to
be
able
to
make
that
work
better,
but
that's
gonna
end
up
in
the
RFC
and
or
maybe
in
a
working
group.
We
end
up
building
something
like
that
to
be
able
to
do
the
extended
pieces
but
yeah.
Thank
you
and
thanks
listening.
V
Alan
from
Dell
Facebook
I'll
just
board
our
kitchen,
guys
afterwards
and
point
to
you
to
a
draft
that
Wow
and
I
have
written,
which
is
about
it's
an
extension
to
HTTP
2.
That
enables
a
lot
of
this
more
bi-directional
server
to
client
messaging,
and
it
may
be
something
that's
appropriate
for
you.
This
great.
X
Patch
formats
for
different
mime
types
I
have
in
software
that
I've
written
there's
also
Jason
merge.
Jason
Patric
shortie
exist
as
Ayana
documents,
so
we
can
use
those
for
now,
I'd
like
to
add
some
more,
for
example,
collaborative
real-time
text
editing,
but
we
can
move
to
that
when
we
need
to
I
just.
X
L
L
So
I'd
be
interested
in
talking
some
more
about
the
relationship
between
HTTP
methods
and
when
semantics
and
server
push
it's
a
tricky
conversation,
because
the
there's
some
misalignment
between
the
various
models
but
I'm
kind
of
enthusiastic
about
this
idea
that
we
could
do
something
richer
with
with
the
content
that
we
have,
and
certainly
the
suggestion
that
you
might
do
this
with
something
as
simple
as
JSON,
with
with
the
suite
of
tools
that
we
already
have.
So
that
would
be
would
be
quite
interesting.
Yeah!
L
Y
I
knew
yankton's
either
side,
Moses
came
up
stuff,
so
come
talk
to
me
afterwards.
I
was
going
to
say
that
when
we
were
looking
that
one
of
the
this
things
we
mainly
about
change
to
a
single
document,
whereas
one
of
the
big
things
we
need
to
deal
with
was
more
cache
invalidation
to
a
big
collection
of
documents
and
where
some
might
have
changed.
One
of
the
things
that
seems
to
be
a
bit
of
a
different
space.
O
I
continue
to
be
interested.
I
want
to
point
out
a
few
interesting
problems,
one
of
which
is
when
you
are
having
to
have
multiple
uploads
to
the
same
place.
This
often
happens
in
video
for
live
streams,
and
you
have
to
be
able
to
show
that
they
are
actually
part
of
the
same.
You
can't
actually
trust
the
clients
to
get
that
right,
and
so
you
actually
have
the
transactional
problem
in
both
directions,
which
I'm
not
seeing
right
now.
O
X
A
And
just
add
one
personal
comment
from
me:
I'll
echo
a
lot
of
the
comments
we
heard
in
the
queue.
This
is
very
interesting
because
there's
a
lot
of
effort
being
put
right
now
into
coming
up
with
solutions
for
low
layer
transports
for
web
stuff,
various
layers.
But
you
know
as
a
CDN
and
an
intermediary
person,
it's
a
lot
harder
for
me
to
add
value
to
that.
If
we
can
talk
about
the
higher
level
concepts,
it's
easy
to
think
about
how
you
can
scale
that
out
and
do
interesting
things
with
it.
But
but.