►
From YouTube: IETF100-HTTPBIS-20171113-0930
Description
HTTPBIS meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
B
Likewise,
this
is
an
environment
where
we
want
to
keep
it
professional.
We
have
an
Ombuds
team.
Sorry,
Ombuds
team
I
always
get
that
wrong.
If
you
feel
that
you
have
an
issue
where
someone's
behaving
unprofessionally
harassing
you,
you
can
contact
them
and
they
are
the
three
people
at
the
bottom
of
the
slide
the
blue
sheets
are
going
about.
We
have
a
scribe
and
Gabriel.
Thank
you
once
again,
can
someone
act
as
a
job
or
a
relay
for
any
questions
that
come
up
there?
Anyone
I
have
a
hand
in
the
back.
B
Thank
you
that
was
Ted
and
agenda
Bash.
Today,
our
session,
we're
gonna,
have
about
thirty
seconds
talking
about
the
contribution
policy
to
make
sure
that
everybody
understands
what
we
did
there.
We
have
a
session
of
proposed
work,
so
Mike's
going
to
talk
about
secondary
certs,
Patrick's
gonna
talk
about
WebSockets
and
h2
and
I'm
going
to
talk
about
HTTP,
Terr
or
a
business
or
primer
or
whatever
we
decide
to
call
it
and
then,
depending
on
time
of
variable
available,
we'll
talk
about
some
related
work
that
might
eventually
be
proposed.
B
B
B
C
So
the
slides
coming
up
here,
secondary
search,
is
something
we've
talked
about
a
bit
in
the
past.
We
have
been
kind
of
quiet
about
it
for
the
last
couple,
IT
ups,
it
was
on
time
permitting
for
Prague.
This
is
an
idea
that
grew
out
of
some
limitations
that
we
were
struggling
with
between
TLS
and
HCV.
C
I
will
very
briefly
recap
it,
because
I'm
assuming
most
of
you've,
heard
the
discussion
in
the
past
and
then
I'll
talk
about
where
we
are
and
where
we
had
from
here.
So
next
slide,
so
as
we're
probably
all
familiar
with
TLS
gives
you
one
server
certificate
and
at
most
one
client
certificate.
So
if
you
have
a
case
where
a
server
possesses
multiple
server
certificates
too
bad,
you
got
to
pick
one
for
the
connection
and
you
get
a
client
certificate.
Tell
us
one
point:
three
limits
your
ability
to
present
the
client
certificate
later
in
the
connection.
C
While
you
are
renegotiating
to
present
the
cert
and
then
there's
a
more
fundamental
problem
when
you're
trying
to
do
hg
p2
with
that
next
slide,
we
prohibit
renegotiation
and
http2
anyway,
so
you
effectively
can't
present
a
clan
certificate,
so
this
work
grew
out
of
number
one.
We
have
enterprise
cases
that
still
use
client
certificates
that
we
really
would
like
to
move
to
http.
C
We
don't
want
to
stick
them
on
HTTP,
1-1
or
even
worse,
run
them
over
HTTP,
2
and
then
fire
on
HTTP
one
one
required
error
at
them
as
soon
as
you
need
a
certificate,
so
they
start
the
connection
over
and
then
we
negotiate
and
present
the
serve
and
the
work
that
led
into
this
was
once
we
had
a
mechanism
to
present
a
client
cert
at
the
HTTP
layer.
You
could
just
as
easily
present
a
server
cert
at
the
HD
view
layer.
So
next
slide.
C
The
extension
relies
on
a
draft.
That's
been
adopted
in
TLS.
Now
that
it's
called
exported
authenticators,
it
says:
once
you
have
a
TLS
session
established,
you
can
export
a
blob.
That
proves
that
you
have
a
certain
other
certificate
than
what
you
negotiate
and
TLS,
and
then
we
use
HTTP
frames
pass
these
around
and
say.
C
I
would
like
to
see
your
cert,
for
example,
calm,
and
then
the
server
can
send
back
the
example.com
search
and
vice-versa,
if
you
want
to
do
client
certificates,
the
server
can
be
very
precise
about
for
this
request.
I
need
a
client
certificate
that
looks
like
this
and
the
client
can
return
him.
So
if
you
want
to
look
at
the
flows
next
slide,
when
you're
dealing
with
servers,
the
server
might
send
you
an
Origin
frame
that
asserts
it
is
authoritative
for
more
domains
than
is
and
then
are
in
its
TLS
certificate.
C
In
which
case
the
client
would
say,
I
would
like
to
see
the
certificates
for
these
domains.
They're
interesting
to
me,
and
the
server
proves
that
it
has
a
certificate
chain
that
maps
up
to
that
dummy,
and
at
that
point
the
client
would
be
willing
to
make
requests
and
coalesce
more
broadly
onto
a
connection
than
they
could
with
a
single
certificate
and
next
slide.
C
If
you
look
at
the
client-side
clients
make
a
request
and
what
happened
the
nunchi
p11
over
TLS
is
that
at
this
point
the
server
would
renegotiate
and
say
I'd
like
to
see
your
client
certificate
before
I
answer
that
and
so
in
TN
HCP,
or
it
should
be
over
quick
for
that
matter.
We
would
be
able
to
do
effectively
the
same
thing
without
relying
on
we
negotiation
that
TLS,
the
server
can
say.
Well,
here's
the
definition
of
a
certificate
I
like
to
see
and
I'm
requiring
it
on
this
request.
C
This
also
gives
you
a
way
to
do
encrypted,
S&I
that
you
can
open
the
TLS
connection,
asking
for
one
certificate
and
then
in
your
0tt
data,
say,
and
I
would
also
like
to
see
your
certificate
for
sensitive
info
comm
on
the
client
side.
Client
certificates
are
a
real
thing.
It's
kind
of
a
pain
not
having
them
in
HTTP
too,
and
at
Microsoft.
That
was,
and
that
had
not
been
a
problem
until
we
shipped
the
version
of
Windows
Server
that
supported
htv-2.
C
C
Like
I
mentioned
this
uses
the
exported
Authenticator
straps
that
Nick
Sullivan
has
done,
and
that
has
been
adopted
in
the
TLS
working
group
in
Chicago
because
we
were
asking
for
it
and
this
draft
has
basically
been
on
hold.
While
that
makes
some
progress,
it
is
now
moving
forward
in
the
TLS
working
group
at
Nick.
Are
we
close
to
last
call
at
this
plant
or
yes,
okay,
we've
had
some
discussion
over
the
weekend
at
the
hackathon.
C
There
are
probably
some
properties
that
we
need
to
change
and
exported
authenticators
and
take
advantage
of
here
to
get
a
few
better
bindings
between
requests
and
responses,
but
in
general
that
is
moving
forward
and
I.
Think
that
means
it
is
time
to
ask
the
question
on
the
HTTP
side.
Are
we
ready
to
adopt
this
because
it
now
no
longer
depends
on
an
individual
draft?
It
depends
on
a
working
group
draft
until
us
and
that's
what
I
got
right.
D
Ted
Hardy
clarifying
question.
One
of
the
use
cases
that
you
actually
described
in
the
draft
is
the
use
case
that
common
in
TLS,
where
you
wish
to
present
a
generic
certificate
or
or
similar
and
then
negotiate
to
a
more
specific
or
different
certificate,
so
that
you
don't
reveal
what
you're.
Looking
for
in
the
s
and
I
I
understand
that
there's
also
work
on
similar
discussions
going
on
inside
the
TLS
working
group.
Is
it
anticipated
that
you
would
continue
to
describe
it
here
or
rely
on
it
coming
from
a
more
generic
mechanism?
I
think.
E
Oh
great,
let's
gonna
model,
Thompson
I
think
the
idea
is
this
would
be
complementary
to
whatever
TLS
does
so.
Tell
us
who
are
looking
more
for
a
generic
solution,
or
is
this
I
think
would
present
a
path
for
HTTP
and
could
present
a
path
for
other
protocols
that
decide
to
adopt
a
similar
sort
of
scheme,
but
I,
don't
and
I
think
we're
attempting
to
address
the
general
problem
here
with
this.
D
Okay,
I
think
that
that's
a
fine
clarification
thank
you
very
much.
I
would
suggest
at
that
point
then,
if
this
is
gonna
continue
to
be
in
this,
that
that
particular
use
case
get
could
been
more
discussion
in
the
draft,
especially
around
how
it
interacts
with
the
HTTP
origin,
because
I
I
think
you
you
treat
that
in
some
other
aspects
that
draft
much
more
completely
than
it
currently
does,
but
I'm
fine
with
adopting
it
and
doing
the
work
in
the
working
group
to
do
that.
A
E
C
F
Lastly,
I
think
that
this
draft
is
ready
for
adoption
I'm
interested
in
implementing
it.
On
the
other
hand,
I
have
a
technical
question
and
I
wonder
if
it
would
be
possible
to
let
the
client
always
specify
the
such
that
is
associated
to
the
request.
Instead
of
letting
the
server
choose.
One
I
asked
this
because
CGI
or
Fosse
I
expect
the
client
space
by
just
one
such
it
for
every
request,
and
it
is
awfully
impossible
for
HTTP
server
to
determine
which
certificate
is
associated
to
each
request.
I.
C
C
So
some
of
the
changes
that
we've
been
discussing
the
hackathon,
probably
are
going
to
mean
we
no
longer
support
the
client
spontaneously
sending
certificate
and
saying
you're
going
to
want
this
trust
me,
which
is
probably
okay,
but
once
the
certificate
has
been
sent
on
the
connection,
then
saying
request
by
request
end.
Yes,
please
use
certificate
numbers
in
number
one
for
this
request
without
the
server
having
first
ask
for
that
request
and
saving
a
round-trip
that
should
be
doable.
B
B
A
Good
morning
good
morning-
and
this
is
not
hai
bhai-
this
is
HTTP.
This
next
slide.
Okay,
as
we've
heard
for
a
number
of
years,
64
55,
which
describes
the
WebSocket
protocol
as
it
likes
to
call
it
in
all
capital.
Letters
uses
a
bunch
of
HTTP
one
specific
mechanisms
to
bootstrap
itself,
so
it
uses
connections,
host,
headers
and
upgrade
all
of
which
were
removed
from
HTTP
2
because
they
have
connection
wide
scope
and
conflicted
with
the
multiplexing
is
fundamental
to
7540
in
HTTP
2.
A
So
you
know,
we've
been
hearing
about
this
this
for
a
number
of
years
about
this
mismatch,
and
the
website
community
was
very
interested
in
having
native
h2
support
and
I
have,
from
time
to
time,
put
a
bunch
of
energy
into
trying
to
determine.
You
know
what
the
real,
what
the
real
needs
are
there.
So
I
had
a
hypothesis
for
quite
a
while
that
you
know
the
multiplexing
and
therefore
the
priority
that
has
to
go
with
the
multiplexing
features
of
HTTP
2
could
really
benefit
WebSockets,
but
it
turns
out
really.
A
You
know
the
the
desire
from
that
community.
By
far
the
top-level
goal
that
was
stated
was
they
didn't
want
to
maintain
a
separate
HTTP
one
stack
just
to
bootstrap
WebSockets.
Those
other
features
of
HTTP
2
might
maybe
be
a
bonus,
but
the
real
problem
was
an
administrative
one
in
many
respects.
Maintaining
HP
one
stack
just
for
the
purpose
of
running
their
WebSockets
stack.
A
Ok,
so
next
slide
with
that
in
mind,
we
talked
about
this
at
a
non
IETF
event
and
the
HTTP
workshop
in
London
last
June,
and
we
talked
through
some
of
the
native
htv-2
proposals
that
have
failed
to
gain
traction.
You
know
in
this
space
and
I
suggested
we
could
do
the
absolute
minimal,
Viable
Product
here,
which
was
just
to
take
64,
45
or
60
for
55
rather
and
tunnel
it
on
an
HTTP,
2
string
stream.
So
you
would
still
have
other
HTTP
2
streams.
They
could
run
other
copies
of
WebSockets.
A
This
is
run
normal
HTTP
data.
They
could
do
whatever
they
want
and
those
would
be
multiplexed
with
each
other,
but
within
the
individual
stream.
Just
like
on
a
connect
tunnel
when
you're
connecting
through
a
proxy,
for
instance
on
that
individual
stream,
it
would
run
another
protocol
in
this
case
64
55.
So
the
scope
of
what
I'm
proposing
here
is
limited
to
http,
choose
initiation
of
64,
55
and
I.
Think
that's
a
suitable
topic
rate
to
be
this.
To
talk
about.
You
know
changes
to
the
WebSocket
protocol,
including
things
like
masking,
which
is
everyone's
favorite.
A
You
know,
I,
don't
think
are
best
done.
You
know
in
this
room
like
hi
bye
was
the
group
that
originally
developed,
WebSockets
and
I.
Think
would
be
great
if
someone
wanted
to
build.
Some
extensions
to
the
WebSocket
protocol
would
continue
to
do
that
through
someone
who
is
chartered
to
work
on
that
kind
of
problem.
A
Okay,
so
there's
a
draft
up
there
and
individual
draft
there's
a
no
we've
been
circling
the
list
for
a
little
bit,
but
actually
got
technically
published
this
morning
when
data
tracker
reopened
and
what
it
does
is.
It
uses
an
h2
opt-in
extension
to
create
an
extended
connect,
so
the
extension
mechanism
of
7540
lets
you
do
pretty
much
anything
you
want
with
negotiated
extensions,
and
this
makes
a
change
to
what
Connect
does
so
connect
fundamentally
already
builds
tunnels,
which
is
why
I
find
it
really
interesting
for
this
work.
A
You
know,
but
it
is
defined
to
make
them.
You
know
in
proxies
using
TCP
to
tell
them
to
a
different
host
and
port,
and
this
really
extends
connect
to
apply
to
the
origin
server
instead
of
proxy.
It
doesn't
require
the
external
connection.
Okay
Connect,
as
I
like
to
say,
is
already
a
special
snowflake
in
our
documents.
It
works
hop
hop
really,
unlike
other
methods,
it
builds
bi-directional
tunnels
it
doesn't.
A
You
know
anticipate
that
the
request
needs
to
finish
before
the
request
starts
and
all
that
kind
of
thing
in
that
kind
of
way,
it's
a
pretty
good
match
for
what
we're
trying
to
accomplish
the
other
option
that
folks,
love
to
you
know
to
debate
here
is
whether
the
old
h1,
semantics
of
a
method
like
GATT,
with
an
upgrade
header,
is
a
is
a
better
fit.
The
way
I
kind
of
look
at
those
things
is
that's
really
an
option.
Opportunistic
version
upgrade
you
know
over
a
real
requests.
A
So
from
the
document,
here's
an
example
of
of
what
it
would
look
like.
So
you
see
we're
going
to
preserve
much
of
the
way
64
55
works,
so
you
you
initially
have
you
know
an
opt-in
setting.
The
server
has
to
tell
you
that
you
can
do
this,
and
then
the
client
puts
together
connect
requests
with
an
authority
which
now
means
this
is
the
origin
rather
than
where
I'm
trying
to
tell
through
to
and
a
bunch
of,
the
things
defined
by
64
55.
F
A
Headers
of
what
you
need
to
negotiate
there's
a
little
bit
in
the
WebSocket
protocol.
This
is
designed
fund
alone
and
fundamentally,
to
make
sure
that
JavaScript
content
can't
create
something
that
looks
like
a
WebSockets
handshake
that
isn't
really
WebSockets.
That
is
not
needed
in
this
case,
because
one
of
the
key
aspects
of
this
of
this
proposal
is
a
new
pseudo
header
called
protocol,
which
is
something
that
a
xhr
or
a
JavaScript
basic
application
can't
can't
create,
and
so
he
accomplishes
the
same
thing
a
little
bit
easier.
A
My
early
drafts
had
a
pure
tunnelling
application
where
you
actually
essentially
just
created
a
blind
pipe,
and
you
did
a
one
like
or
actually
use
the
h1
syntax
within
the
tunnel
that
was
connected
here.
People
preferred
to
move
that
metadata
things
like
the
protocol
version,
the
sub
protocols,
the
extensions
etc.
You
know
outside
that
the
way
it's
traditionally
been
done,
so
this
draft
reflects
this.
So
that's,
basically
what
we
got
for
an
overview.
A
There's
been
a
whole
lot
of
discussion
on
this
for
an
individual
draft.
Thank
you.
That's
always
you
know
motivating
right
and
so
I
think
if
we
keep.
If
we
keep
this
narrow
just
on
the
bootstrapping
mechanism,
rather
than
trying
to
read
them
at
the
ocean,
I
think
we've
got
a
potential
answer
here
to
a
long-standing
nagging
problem.
So
I
would
like
to
suggest
we.
You
know
we
adopt
this.
E
The
queue
for
Martin
Thompson
I,
like
some
of
the
properties
of
this
I,
like
the
fact
that
you've
essentially
taken
the
bootstrapping
part
of
64
55
and
said.
Well,
we
don't
any
of
that
and
taking
the
bits
that
you
actually
need
and
put
it
in
the
in
the
head
of
fields,
but
that's
a
more
natural
translation
I
like
the
fact
that
you
signal
that
that
you
support
the
particular
thing.
E
Obviously,
if
someone
puts
a
:
protocol
in
an
HTTP,
2
header
block,
the
explosions
will
happen
and
that's
actually
kind
of
a
property
that
I
like
as
well
is
that
this
is
not
going
to
happen
by
accident
and
if
it
does
happen
by
accident
connections
will
die.
So
it's
self-correcting
fairly
quickly.
I
think
this
is
probably
the
right
way
to
do
things
and
yeah.
As
you
say,
let's
keep
the
translation
as
simple
as
possible.
This
seems
as
simple
as
I
can
imagine.
E
Oh
I
also
had
to
have
to
point
out
that
I
was
convinced
by
your
arguments
about
connect
over
the
other
of
the
other
methods.
The
fact
that
people
actually
have
rules
on
their
service
that
block
connect,
kind
of
has
the
right
effect
on
on
this
right.
I
sort
of
took
Marc's
comments
on
a
list
about
that
that,
to
sort
of
imply
that
connect
might
not
work,
but
that
is
actually
an
outcome
that
I
kind
of
like
so
now
that
I
thought
it
I'll.
C
C
B
And
so
mark
Nottingham,
no
hats.
My
discomfort
is
mostly
around
you
know.
Martin
says
it's
it's
virtuous.
If
the
server
refuses
the
connects,
I,
think
I,
you
know,
servers
are
deployed
by
many
parties
and
often
by
multiple
parties
at
the
same
time,
in
different
layers
and
without
a
lot
of
coordination
and
I'm
a
little
concerned
here
that
you
know,
connect
suddenly
tripping
laughs
rules
when
people
try
negotiate.
B
Websockets
may
be
a
scenario
that
causes
people's
nightmares,
so
I've
gone
out
and
started
talking
to
a
few
people
who
do
that
to
figure
out
how
much
of
a
problem
that
really
is
and
I'm
gonna
reserve
further
comment:
I'll
hear
back
from
them,
but
it's
not
quite
as
simple
I
know
that
from
the
browser
side,
you
all
maintain
the
code
base.
You've
got
tight
control
over
that
servers
are
often
not
like
that,
and
I
want
to
see
how
much
pain
is
gonna
cause
I.
B
A
A
A
headers
frame,
which
I
think
would
be
a
far
more
exciting
thing
to
do
right.
The
question
is:
what
do
we
want
to
promote
as
good
practice,
so
I
mean
I
think
here
what
we've
got
specifically
or
the
student
pseudo
headers
apply
to
hop-by-hop
transport,
oriented,
headers
and
I.
Think
that's
applicable
here.
A
A
B
B
F
E
Yeah
mom
Thompson,
just
a
responder
marks
thing.
It
depends
on
whether
you're
considered
having
WebSockets
succeed
as
a
special
goal.
Like
what
what
extent
you
you
consider
the
successive
WebSockets
to
be
to
be
a
goal
and
I
think
to
the
extent
that
there
are
hurdles
to
using
this.
That's
not
necessarily
a
bad
thing.
G
A
A
This
would
be
included,
I
mean
the
way
I
would
implement
this
in
my
server
would
be.
This
option
would
be
included
in
this
first
flight
of
the
server
settings.
Anyhow,
this
isn't
a
different
flight
than
there
are
other
settings.
You
can
include
this
in
the
opening.
You
know
the
opening
setting
preamble
essentially.
E
Yeah
Martin
Thompson
at
that
point,
I
did
some
analysis
on
on
this
and
yes
in
TLS
one
to
this
does
introduce
a
round
trip
over
over
WebSockets.
Previously
the
fact
that
you
actually
have
a
user
on
HTTP,
two
connection-
that's
still
usable
prior
to
that
point-
actually
means
that
it's
not
as
much
of
a
problem
as
as
people
like
to
think
until
s13.
E
This
is
not
a
problem
because
the
server
will
be
able
to
speak
first,
and
so
you
will
have
no
worse
performance
with
WebSockets
the
the
only
cost
there
is
that,
because
you're
waiting
on
the
settings,
you
won't
be
able
to
use
WebSockets
in
zero
ICT,
but
I
think
we
can
live
with
them.
I
should
point
out
if
you
want
to
use
WebSockets
in
0,
RTT,
you've
got
a
whole
host
of
other
problems
that
you
might
want
to
take
a
good
hard.
Look
at
the
whole
replay
thing.
B
A
B
And
so
we
put
a
mailing
list
message
out
a
while
back
trying
to
describe
the
goals
of
such
an
effort
and
to
constrain
it.
So
full
disclosure
I've
expressed
interest
in
acting
as
an
editor
on
this,
as
has
Julian,
and
so
if
we
did,
that
Patrick
would
be
the
acting
chair
for
the
effort
and
he
expressed
I.
Think
a
little
bit
of
discomfort
about
it.
Turning
into
a
large
effort,
let's
face
it
the
last
time
we
did
this.
A
So
I
will
make
the
comment
before
that
my
client
opens
that
you
know
I
think
the
most
valuable
piece
of
this
work
is
really
to
clearly
separate
the
semantic
layer
that
we
somewhat
casually
refer
to
it,
as
you
know,
from
the
other
aspects
of
the
protocol
and
to
write
those
down
of
what
we
can.
What
we
can
depend
on
because
that's
become
you
know
with
h2,
and
there
were
only
sort
of
two
versions
of
this.
We
were
able
to
kind
of
muddle
through,
but
this
clearly
becomes
a
bigger
problem.
You
know
over
time,
yeah
and.
B
B
I
think
I've
heard
this
work
betrayed
as
being
quite
helpful
to
that,
in
that
we
have
a
more
well-defined
target
for
that
other
work
to
look
at,
whereas
right
now
it's
spread
across
a
bunch
of
documents
in
a
somewhat
haphazard
way,
and
so
I
guess
I
was
a
little
surprised
to
hear.
You
say
that,
because
for
at
least
from
my
perspective
you
know
wearing
a
bunch
of
different
hats,
I
think
this
is
good,
provided
we
can
do
it
in
a
reasonable
amount
of
time
and
I.
Think
that's
the
whole
point
here
is.
A
D
Tardy
again
with
the
kind
accession
of
the
people
in
the
line,
I
appreciate
your
comments
and
I
do
see
that
if,
if
this
had
been
done
before
that
work
started,
it
would
clearly
have
some
some
opportunities
to
to
have
exactly
the
the
impact
you
described
with
the
other
work
already
underway.
And
it's
chair
telling
me,
as
as
far
as
you
can
crack
that
whip
I
do
worry
both
about
taking
some
of
the
energy
from
a
fairly
small
group
of
people
who
understand
both
HTTP
and
quick
and
for
forcing
them
to
double
focus
and
I.
D
Do
just
also
believe
that
we
are
continuing
surface
new
things
as
we
go
through
the
quick
exercise
about
what
a
valuable
way
of
expressing
this
in
a
transport
neutral
way
would
be,
and
I
I
think
there's
gonna
be
either
a
little
bit
of
incurred
delay
as
a
result
of
doing
this
at
the
same
time,
or
a
little
bit
of
missed
opportunity
as
a
result
of
doing
it
at
the
same
time,
so
I'm
happy
that
you're
considering
the
matter
carefully,
but
I
I
do
have
some
remaining
caution.
I.
B
Can
understand
that
certainly
I
think
manure,
seeing
it
now
is
gonna
be
a
fairly
focused
effort
by
just
a
few
people.
That's
gonna,
be
validated
by
the
rest
of
the
working
group
and
I
I
suspect
that
this
is
going
to
have
to
happen
anyway
for
a
quick
to
really
be
able
to
map
well
to
http.
But
let's
go
through
the
key
part.
E
Yeah,
so
some
on
Tom's
and
I
think
that
a
good
part
of
the
motivation
for
this
is
is
actually
helping
quick,
get
its
work
done.
That
said,
to
Ted
two
comments,
I
would
I'd
be
a
little
leery
of
publishing
this
before
quick
was
done.
Oh
yes,
just
because
we're
learning
things,
the
one
thing
that
bothers
me
most
about
the
work
program
that
you've
outlined
here
is
is
the
one
point
on
number
four
there
and
that's
the
versioning
thing
well,
I
think
we're
still
learning
about
that,
and
that
may
be.
E
B
Just
to
contextualise
that
we
had
the
those
words
are
lifted
verbatim
from
the
Charter
for
the
original
diss
effort.
We
attempted
to
do
that
then
as
well,
and
we
did
a
lot
and
this
is
not
the
be-all
and
end-all
of
HTTP
extensibility.
It's.
We
need
to
continue
to
document
best
practice
there,
knowing
that
is
going
to
evolve
the.
E
F
B
E
E
I,
don't
think,
to
the
same
extent,
we're
capable
of
saying
anything
definitive
about
how
we
do
versioning,
because
we
got
it
wrong
before
we
did
it
differently
for
age,
we're
doing
it
differently
again,
for
quick
and
I'm,
not
sure
that
we're
doing
it
right
either
and
so
I'd,
like
a
I'd
like
a
little
more
confidence
in
that
before
I
pick
that
out,
and
so
maybe
striking
and
versioned
from
this
thing
and
simply
saying
well,
you
know
it
is
what
it
is
well
document.
What
we
have
is
is
what
we
need
I
hear.
A
B
Happy
to
be
as
aggressive
as
the
working
group
wants
us
to
be:
I
need
to
talk
to
Julian,
of
course,
and
we'll
have
to
come
Feb,
but
I
would
hope
that
we
could
do
this
and
certainly
less
than
a
year
which
would
put
us
on
on.
You
know.
We
I
agree
with
Martin
statement.
I
think
it
was
that
we
don't
want
to
ship
this
before
quick
HTTP
ships,
but
I'd
like
to
have
it
ready
to
go
at
the
same
time.
So
yeah
like
Mike.
C
Bishop
Akamai
and
speaking
ear
as
both
author
of
a
draft
that
talked
non,
talked
about
how
we
decompose
the
semantic
layer
from
the
mapping
and
now
is
the
editor
of
HTTP
over
quick
I
think
this
is
a
separation
that
would
be
really
helpful
as
we
start
to
define
quick
and
as
we
look
toward
the
future,
I
think
the
end
versioned
piece
is
interesting
because,
as
you
observe,
we've
kind
of
gotten
it
wrong.
All
the
versioning
that
we
have
talked
about
has
wound
up
being
versioning
of
the
mapping
and
I.
C
Don't
know
that
we
understand
how
we
version
the
semantic
layer,
because
we've
never
seen
them
as
separate
entities
until
we
kind
of
we're
doing
h2
and
now
that
we're
doing
quick
and
so
that
we
don't
have
a
defined
way
to
version
them
and
if
we
were
to,
if
we
were
to
create
one
that
would
be
a
change
to
http,
which
I,
don't
think
is
in
the
appropriate
charter.
For
this.
C
B
A
It
yeah
from
a
process
point
of
view,
yes,
but
it
incorporates
logically
a
lot
of
7230
by
reference
right,
but
not
all
of
it,
and
that
is
actually
I.
Think
one
of
the
things
you
set
out
to
clarify
right
right,
so
I
think
if
the
question
is
about,
if
this
is
work
or
interested
in
taking
on
I'm
curious,
if
alexei
has
any
comments
you
know
he
would
like
to
make
before
we.
We
ask
the
room
if
they
think
this
is
appropriate.
I.
I
Don't
have
any
objections,
let's
put
it
this
way
and
I.
Think
yeah
I
think
that
there
was
a
good
set
of
concerns
about
timeline
of
related
efforts,
but
I
think
it
probably
will
help
quick,
HTTP
or
quick.
So,
and
my
only
other
comment
is
I'm
would
be
curious.
You
know
how
well
you
can
stick
to
your
proposed
timeline,
so
we
shall
see
well.
B
I,
the
only
thing
that
that
has
caused
real
concern,
I
think
in
our
discussions,
has
been.
There
have
been
a
number
of
cases
where
folks,
from
from
browsers,
especially
doing
other
specifications
that
relate
to
this
have
brought
interoperability
issues
up
or
very
fine
error,
handling
issues
up
and
I
think
we've
come
to
a
place
where
we've
agreed.
We
don't
want
to
address
that
level
of
interoperability,
certainly
for
HTTP
1
and
unless
there
is
a
really
critical
security
or
a
severe
interoperability
issue.
B
And
frankly,
if
it's
a
severe
interoperability
issue,
we've
probably
already
seen
it
so
I
think
we.
That
would
be
the
only
thing
that
would
really
blow
out
our
timeline
as
we
went
through
and
talked
about
how
to
pars
every
header
from
scratch
and
to
find
algorithms
and
all
that
and
I.
Don't
think,
there's
a
will
here
to
do
that.
Okay,.
A
Then
we
take
a
hum
about
whether
or
not
this
is
if
we
were
to
pursue
this
work.
If
people
feel
like
this
is
the
right
timeframe
to
do
this
work
given
what's
going
on
with
quick
and
the
other,
the
other
work
sits
in
front
of
the
working
group.
So
if
you
think
this
would
be
the
right
time
to
initiate
that
work
go
hum
yester
the
first
time
and
if
you
think
this
is
simply
not
the
right
time
either,
because
you're
opposed
to
the
work
or
you
just
think.
A
A
A
B
Hello
again,
I'm
gonna
talk
briefly
about
variance
a
relatively
new
draft
that
I've
put
up
I'll,
go
ahead
and
press
space
so
ya
in
HTTP.
We
have
this
notion
of
secondary
cache
keys.
Where
the
primary
use
case
is.
You
know
we
want
to
be
able
to
cache
something
that
we've
used
proactive
content
negotiation
where
you
use
you
know
a
request
header
to
indicate
the
clients
preferences
and
the
server
selects
response
based
upon
that
request,
header,
so
content,
codings
content,
language
is
content
formats.
Also,
we
have
a
new
working
group
draft
we're
not
new.
B
Now
anymore,
it's
been
around
for
a
while,
but
new
to
implementations
planes
to
do
this
on
we're
calling
client
hints,
which
is
really
just
a
collection
of
new
content
negotiation
axes
for
things
like
the
device,
pixel
ratio
or
the
window
widths
that
the
browser
currently
has
mark
I'm.
Sorry,
you
may
need
to
come
back.
A
A
B
You
go
okay,
and
sometimes
you
know
we.
We
have
used
this
in
the
negotiating
for
things
like
user
agents
and
cookies
and
stuff
like
that
too
next
slide,
so
the
the
currently
specified
way
to
do
this
is
the
very
header
in
RFC
7230
for
and
it
is
very
coarse-grained.
It
can
only
consider
an
entire
request
as
a
string
effectively
as
that
secondary
cache
key.
B
You
can
do
some
canonicalization,
but
that
isn't
really
well-defined,
and
so
we
have
drifting
the
implementation,
their
correct
implementation,
where
you
actually
correctly
applied,
is
quite
expensive
because
it
requires
you
to
kind
of
touch
a
lot
of
different
things
in
your
cache.
And/Or
keep
a
lot
of
things
in
memory
and
and
a
lot
of
implementations
as
a
result.
Take
shortcuts
in
implementing
this
so
Interop
isn't
great
and
the
functionality,
because
it's
so
coarse-grained
is
quite
limited.
We
hope
we
can
do
better
next
slide.
B
Given
request-
and
so
you
say-
okay,
you
know
this
key-
incorporates
the
user
agent
and
there's
a
sub
screen,
it
string
in
it,
and
if
the
sub
string
includes
msie,
then
you
go
into
one
bucket
and
then
you
also
can
have
a
substring
for
mobile
and
that
goes
into
a
different
bucket
and
then
incorporate
cookies
and
there's
kind
of
a
way.
You
combine
these
things
into
a
logical
key
for,
for
that
particular
request,
and
so
that's
much
finer
grained.
You
can
target
different
parts
of
the
header
for
your
secondary
cache
key.
It's
also
deterministic
you.
B
You
know
you
have
an
algorithm,
you
go
through
and
that's
how
you
use
but
identify
this
in
your
cache
key,
and
hopefully
that
means
that
the
implementations
will
be
much
more
aligned.
But
you
know:
we've
had
it
out
there
for
a
while.
It's
sat
there,
we've
been
asking
for
implementation
feedback
for
quite
some
time
and
and
the
general
feeling
that
I
get
is,
is
that
it's
got
a
couple
of
really
significant
downsides.
B
You
know
we're
creating
a
little
miniature
language
here
for
describing
the
secondary
cache
key,
and
there
are
a
lot
of
trade-offs
that
you
need
to
make
it
in
in
the
creation
of
that
language,
to
make
sure
it's
compact
and
relatively
flexible
and
we're
not
still
certain
that
we've
made
the
right
trade-offs,
we're
just
not
there
and
so
thinking
about
it
and
talking
to
prism
folks
slide.
We
have
a
new
proposal
which
is
actually
informed
when
I
recently
joined
a
lovely
new
employer.
B
How
do
I
select
given
a
set
of
these?
How
do
I
select
the
appropriate
one,
given
the
clients
preferences,
so
the
client's
expressing
their
preference
in
a
request,
header,
and
then
you
identify
on
the
response
which
ones
of
those
were
actually
used
in
the
variant
key
and
between
those
two
bits
of
information.
Now
the
intermediary
has
the
ability
to
select
any.
You
know
the
appropriate
response
for
any
given
request
and
that
works
really
well.
B
It's
not
as
suitable
for
request
headers
with
opaque
semantics,
which
was
one
of
the
key
sorry
one
of
the
primary
usage
scenarios
for
key
people
wanted
to
negotiate
on
things
like
cookies
and
and
so
one
way
to
view
variant
is,
is
it's
a
supplement
to
key
where
it's
not
trying
to
target
cookies?
And
it's
not
trying
to
target
a
user
agent?
It's
going
for
well
understood
axes
of
content,
negotiation!
B
I
myself,
wonder
if
maybe
once
we
do
this,
it
might
be
good
enough
to
get
rid
of
key
altogether
and
it
could
be
possible
to
maybe
retrofit
this
onto
cookies,
but
I
don't
want
to
explore
that.
What
yet
and
the
other
plus
is
it's?
It's
simple
and
intuitive
to
author.
It's
it's
much
easier
than
key
I!
Don't
know
if
there's
a
next
slide!
No
okay!
So
that's
about
it.
Like
I
said,
my
current
employer
does
have
a
form
of
deployment
experience
with
this
and
it
works
really
well.
B
This
is
a
much
bigger
generalization
of
that.
No
I
don't
have
IPR
to
declare
on
that
and
I've
checked
into
that.
You
can
also
view
it
as
something
that
is
very
similar
to
transparent
content
negotiation.
Not
sorry,
not
TCN,
no
TCN,
where
you
list
all
the
different
variants
available.
The
difference
here
is
this
is
a
much
simpler,
more
straightforward,
HTTP
specific
way
to
do
it
and
so
I'm
asking
for
feedback.
A
E
B
And
yeah:
that's
exactly
right.
The
first
version
of
variance
actually
conflated
that
so
that
it
was
conflated
the
the
key
selection
with
existing
response
headers,
and
for
that
reason
that
you
put
out
that
there
might
be
a
partial
matrix
that
seemed
to
be
a
bad
idea.
So
that's
why
we
have
a
separate
variant:
key
head
yeah.
This.
F
B
J
K
B
So
there
are
a
couple
of
answers
to
that
when
the
cache
evaluates
a
request.
It
uses
ideally
the
most
recent
variants
header
for
that
resource
that
it
has
received
and,
of
course,
if
it
doesn't
have
anything
cache
they'll
have
to
go
back
to
the
origin.
You
still
send
the
vary
header
with
this,
because
you
still
have
to
interoperate
with
caches
that
don't
understand
variants,
and
it
might
be
that
you
list
more
things
in
the
vary
header
than
you
do
in
variants.
B
A
Take
off
my
chair
hat
and
express
some
skepticism
about
that,
but
I
would
like
to
say
that
this
has
come
up.
This
is
actually
sells.
A
sweet
spot
that
has
come
up
with
h2
push
and
push
cache
interactions.
This
is
I,
think
exactly
the
kinds
of
things
that
get
pushed
that
may
not
be
able
to
be
used
because
of
often
like
image,
negotiation
and
format,
so
that
kind
of
things
is
is,
is
clearly
becoming
a
problem.
B
A
B
If
anybody
is
interested
in
in
doing
some
experimentation
or
experimental
implementation,
I'd
love
to
chat
I,
don't
think
I'm
asking
for
adoption
yet,
but
I'm
I
think
the
discussion
that
would
be
nice
to
have
is,
if
we
adopt
this,
do
we
replace
key
with
it
or
not,
because
I'm
still
not
detecting
I
mean
all
the
interests
that
I
detecting
key
is.
This
is
an
important
space
to
be
working
in,
but
not
this
particular
solution.
So
I
think
this
might
be
a
better
solution.
Yeah.
A
I
would
want
to
pursue
that
line
of
discussion
because
key
has
just
been
parked
with
no
activity
for
a
while,
and
certainly
if
we
wanted
to
adopt
this
I
would
do
this
serve
as
a
wholesale
replacement.
I,
don't
much
care
whether
this
becomes
you
know
and
plus
one
of
key
or
you
know
we
swap
the
documents
whatever
logically
speaking
it,
and
we
can
always
resurrect
key
down
the
road.
If
we
suddenly
decide
we
need
it
sure.
So,
we've
got
five
minutes
left.
Thank
you
mark
Siobhan.
L
Hello,
my
name
is
Siobhan
and
I've
been
working
with
the
HR
PC
research
group
on
things
related
to
HTTP
status
code
451
for
the
past
few
months,
and
the
purpose
of
this
talk
is
to
put
forth
what
we
have
and
get
comments
and
feedback
on
what
would
be
the
right
way
to
move
forward
next
slide.
Please
next
slide,
there's
no
time
for
outlines,
so
the
purpose
of
HDTV
451
is
to
make
censorship
more
transparent.
L
Next
slide,
please,
and
it
should
include
an
explanation
in
the
response
body,
so
the
the
the
work
would
be
read
it
to
see
what
like
these
status
codes,
look
like
in
the
wild.
We
didn't
really
see
any
of
these
explanations
ever
and
it
should
also
include
a
header
field
that
has
the
block
by
information.
This
was
a
source
of
confusion
in
most
of
the
the
instances
we
saw
because
some
of
them
some
people
interpreted
this
to
mean
the
organization
that's
blocking,
as
in
who's
actually
implementing
the
block.
L
L
So
at
IIT
899
hackathon
we
wrote
some
plugins
client-side
plugins
that
would
report
instances,
instances
of
51
and
report
those
back
to
a
back-end
collector,
and
we
also
wrote
some
drafts
next
slide.
Please,
and
so
one
of
them
was
the
implementation
report
draft
where
we
examined
current
usage
patterns,
and
we
also
made
some
recommendations
which
were
captured
in
another
draft
next
slide.
L
So
the
recommendations
that
we're
making
are
having
a
blocking
Authority
link
here
are
similar
to
blur
by
so
you
can
make
clear
distinction
between
these
two
things
and
also
because
we
feel
it's
important
information
and
we
also
also
having
a
provisional
header
for
the
geographical
scope
God,
so
that
we,
because
blocks
were
often
that
we
saw
were
often
scope
to
countries.
So
this
would
be
extremely
useful
information.
So
what
the
form
that
this
would
take?
We're
still
talking
about
that.
But
I
guess
we'll
be
thinking
right
now
is
having
alpha-2
country
codes.
L
That's
also
a
thing
relevant
next
slide,
so
I
guess
the
main
question
we're
asking
is:
what
is
the
right
way
to
move
forward
on
this,
and
should
we
be
looking
at
an
RFC,
seven,
seven
to
five
base
which
combines
the
Human
Rights
protocol
considerations,
plus
the
new
protocol
elements?
And
so
and
as
I
mentioned,
we
are
also
looking
for
more
definition
of
the
geographical
scope
block.
That's
it
so.
E
My
question
was:
if
you're
talking
about
restricting
the
geographical
area
to
a
country
code,
that
sort
of
implies
that
you're
narrowing
the
set
of
options
for
blocking
authorities
to
the
same
extent
is
there.
Is
there
any
sense
in
having
both
fields?
If
you
have
the
blocking
Authority
so
say,
I
identify
a
particular
government
that
is
a
government
of
a
particular
country.
Is
there
any
sense?
You
know
also
identifying
the
country
at
that
point,
so.
L
E
That's
a
good
point,
so
my
point
being
is:
if
you're
going
to
keep
both
of
the
fields.
I
think
you
you
might
want
to
have
a
little
more
detail
in
the
in
the
geographical
area.
Of
course,
as
soon
as
you
get
into
that,
then
we're
getting
into
a
huge
mess
and
we've
got
some
experience,
we're
doing
geolocation
stuff
in
this
organization
and
it's
unpleasant
to
say
the
least,
coming
up
with
a
with
a
format
that
will
actually
describe
where
something
is
linked.
E
M
Sander
Bremen
Texas
A&M
University
three
points.
One
is
that
by
using
the
word
censorship,
it's
a
very
broad
meaning,
it
could
be
fraud,
it
could
be
any
kind
in
a
number
of
things
that
we
would
not
typically
treat
a
censorship,
but
are
legitimate
reasons
for
shedding
something
down.
Second,
gia
geography
is
interesting,
but
if
you're
talking
about
the
law,
you're
talking
about
legal
jurisdiction,
geography
and
legal
jurisdiction
are
two
separate
questions.
M
It's
worth,
including
them
both
because,
of
course,
many
countries
try
to
exercise
jurisdiction,
extraterritorially
and
do
so
successfully
and,
of
course,
as
long
history
of
that
complexity
in
the
Internet.
The
second
thing
about
jurisdiction
is,
it
allows
you
to
go
below
the
national
level.
It
could
be.
State
law
could
be
municipal,
ordinance
and
so
forth,
and
the
third
thing
is
that
you've
got
should
for
the
reason,
but
just
as
technical
people
legitimately
criticize
those
in
the
legal
world
for
trying
to
assert
something
about
technical
design.
That
has
nothing
to
do
with
how
it
run
works.
M
M
B
B
Ok,
we'll
chat
with
you
a
bit
more
perhaps
and
Adrian
had
a
presentation
about
payments
which,
in
Port,
when
we
don't
have
time
to
get
to
what
I
might
ask
is,
is
that
if
he
and
Patrick
and
I
and
Alexei
and
maybe
Wendy,
can
meet
right
afterwards
to
have
a
quick
chat,
we
might
be
able
to
give
you
the
feedback
you
want.
So
that's
for
today
we'll
see
everyone
on
Friday.
Hopefully
thank
you.