►
From YouTube: IETF103-HTTPBIS-20181106-0900
Description
HTTPBIS meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
C
Going
alright
is
9:01
good
morning
welcome
to
HDTV
this.
If
you
don't
intend
to
be
in
each
this,
you
should
risk
it
reconsider
that
thought,
because
this
is
the
this
is
the
right
place
to
be.
In
my
opinion,
Chris
is
gonna,
help
us
out
scribe
in
its
gonna.
Do
it
right
in
the
ether
pad,
if
other
people
want
to
help
him.
This
is
his
first
time
describing,
and
thank
you
for
that,
sir.
If
other
people
want
to
help
them,
that
would
be
great
as
well
before
we
get
going.
C
We
need
one
jabber
relay
I
have
accidentally
omitted
this
in
the
past,
as
a
major
chair
faux
pas,
so
I
do
need
someone
to
volunteer
to
do
to
jabber
anyone
jabber
jabber,
alright
excellent,
thank
you
David,
alright,
so
we
are
set
on
that.
The
blue
sheets
pass
them
out.
Mark's
gonna
pass
up
the
blue
sheets.
C
Okay,
this
is
the
note.
Well
note
it
well,
it
is
day
two,
so
you
have
seen
it
before,
but
these
are
the
is
the
first
meeting
of
the
day.
So
we'll
call
your
attention.
These
are
the
general
rules
that
govern
your
participation
in
this
meeting
and
all
means
this
week.
If
you
haven't
seen
it
and
feel
free
to
come
talk
to
your
chairs
or
your
ad,
we've
got
a
Lexie
sitting
there
in
the
second
row,
I'm
sure
he'd
love
to
talk
to
you
about
the
note
well,
I.
C
We
will
get
to
the
agenda
here
in
in
a
moment.
Here
is
there's
an
agenda
of
these
slides
for
both
today
and
for
Thursday.
As
you
see,
the
both
of
the
work
today
is
in
discussion
discussing
HTTP
core
and
it's
issueless.
I
have
made
one
change
to
the
agenda
last
night
that,
with
the
consent
of
the
group,
I
would
like
to
bring
forward
and
that
is
sort
of
a
Leo's
liaison
activity
with
DNS
op
they're
talking
about
a
new
record
type
that
addresses
the
cname
issue.
C
C
And
so
we've
invited
its
offer
rate
Bellis
over
here
is
Kyle
aid
agreed
to
join
us.
So
if
everyone's
okay
with
spending
you
know
three
minutes
or
so
I
mean
that
may
be
one
question
from
the
floor:
I'm
just
to
make
everyone
aware
of
the
work
that's
going
on
there,
so
they
can
discuss
how
that
interacts
with
you
know
their
products
and
their
needs.
So
that
being
said,
we're
going
to
make
comments
on
today's
agenda
new
additions
and
subtractions.
To
that
addition.
C
Okay,
we
have.
We
have
no
objections,
so
that's
great!
So
how
are
we
doing
on
bootstrap?
We
got
jabber,
we
got
minutes.
We
have
those
blue
sheets,
we
have
added
a
new
co-chair,
which
is
great,
but
he
is
chairing
a
different
working
group
at
this
moment
so
time
time
Johnny
day,
and
you
can
tell
that
he
was
that
it
so
reasonably
that
we
didn't
manage
to
make
that
conflict
in
terms
of
the
agenda
and
we
should
know
just
for
you
know,
work
product
of
the
working
group.
D
C
Http,
so
thank
you
all
to
all
of
those
authors
for
making
that
happen,
and
there
are
two
others
that
are
in
the
hands
of
the
is
G
going
through
a
couple
little
bit
of
a
blast
call
and
ad
requests
on
those.
So
with
that
being
said,
this
is
Ray.
Bela
talked
about
his
draft
I
got
slides
here
somewhere.
E
E
Good
next
slide,
please,
and
as
a
result
of
that,
but
somewhat
belatedly
I
put
together
a
draft
on
Saturday
which
was
published
about
a
minute
after
the
submission
window.
Got
open
again
saw
a
minute
pass,
one
on
sorry,
a
minute
past
midnight
on
Sunday
morning,
and
this
is
a
draft
or
a
resource
record
that
is
specifically
designed
to
allow
web
browsers
to
find
content
without
going
through
a
cname
record,
and
specifically
this
also
addresses
the
problem
of
the
fact.
E
We
heard
at
that
side
meeting
that
there
are
various
issues
there
so
V,
which
is
why
the
HTTP
community
hasn't
embraced.
That
my
hope
is
that
this
would
satisfy
the
requires
to
the
community
but
Northpoint.
It's
very
very
easy
to
invent
on
the
dns
side
of
things.
There
have
been
some
other
proposals
that
specifically
a
name
which
add
very,
very
difficult,
complicated
changes
to
DNS
servers,
both
at
recursively
and
the
authoritative
layer,
and
yet
this
bright
time
and
we're
actually
trying
to
simplify
the
DNS
protocol,
also
called
DNS
camel.
E
You
know
the
thing
that
breaks
the
camel's
back.
So
it's
a
record
where,
if
you've
got
sorry,
the
recursive
server
can
optionally
return
the
a
in
the
quad,
a
records
that
are
associate
with
an
HTTP
record,
so
there's
opportunity
for
minimizing
the
maratti
T
to
the
server
it
works,
Legionnaire
subnet.
So
if
you've
got
CD
ends
that
are
doing
geolocation
yeah,
it's
putting
the
resolution
of
the
geo-located
records
and
thright
passed
those
infrastructure
IDs
in
a
recursive
layer.
E
Next
like
this,
so
I
should
touch
on
this
already.
But
basically,
there
is
no
way
as
far
as
I
can
see
to
fix
the
scene
of
the
apex
problem
without
massively
complicating
the
DNS
protocol
and
even
then,
proposals
that
do
that
aren't
gonna
work
very
well
with
Jukka
geolocation
CD
ends
the
downside,
and
this
is
why
we
obviously
need
to
talk
about
this
here.
Is
that
ultimate?
This
would
require
a
small
change
to
the
resolution
code
within
web
browsers
at
the
moment,
you're,
typically
off
from
using
something
else
by
name
we'll
get
a
drone
foe.
E
This
is
a
different
resource
record
type,
so
it's
not
gonna
be
resolved.
All
with
that,
but
I
believe
that,
ultimately,
the
only
way
to
fix
this
problem,
though
afford
is,
for
the
DNS
community
to
move
towards
you
guys
and
the
web
community
to
move
towards
us
and
come
up
with
something
that's
architecturally
sound
and
optimal,
and
thank
you
for
your
time.
We.
F
E
E
E
Please
yeah
I
would
love
to
hear
for
our
particular
from
browser
developers.
What
you
would
see
is
the
impediments
technical
or
otherwise
to
deploying
list
in
your
browser's,
because
we
know
it,
we
done
the
DNS,
and
we
know
the
Dinesen
that
this
particular
part
of
DNS
is
the
right
place.
To
put
it
compared
to
other
admits,
are
hacky
ways
of
getting
around
the
problem,
but
we
need
to
meet
in
the
middle
somewhere,
and
this
I
think
is
the
right
pressure
donut.
Thank
you.
Thank.
C
C
A
A
There
isn't
much
to
the
slides
next
slide,
please,
so
we
had
a
burst
of
activity
in
September
October
and
we
introduced
a
new
set
of
drafts
if
you're
interested.
The
change
notes
are
in
the
bottom
of
each
of
those
drafts
and,
of
course,
they're
gifts
as
well
and
from
the
page
next
slide,
Julian's
been
chucking
away
at
the
errata.
So
currently
we
have
27
valid
errata
14
were
verified,
9
health
update
and
4
were
reported.
So
far,
we've
addressed
at
20
address
22
of
those.
A
There
are
five
that
are
still
open
and
they're
all
mapped
to
different
issues
on
github,
and
we
have
a
separate,
a
Status
page,
which
is
cool
next
slide
yeah.
So
on
github
we
have
around
80
issues
up
and
right
now,
as
mentioned
34
are
those
were
for
a
rad
I
know.
Five
of
those
are
still
open
and
51
are
editorial
with
33
of
those
closed,
that's
the
home
page,
where
we
keep
the
issues
and
all
the
the
stuff.
What
we've
done
for
this
meeting
is
labeled
I.
Think
on
the
order
of.
A
Yeah
14
yeah
14
issues
with
the
discussed
label,
and
so
the
plan
is
just
to
go
and
work
through
those
those
are
ones
that
we
felt
we
needed
input
from
the
working
group
to
make
some
progress.
If
you
have
other
issues
there
on
the
issues
list
you'd
like
to
discuss,
we
can
talk
about
those
too
or
if
you
have
issues
that
aren't
on
the
issues
lists
we
can
get
them
on.
There
make
sense,
you're
out
of
slides
all
right,
I'm
gonna
slides.
Thank
you
for
prepared
preparing
the
slides,
Julian
and
sleep
well.
I.
A
A
A
So
this
is
in
the
cache
and
specification
cache
control,
private
and
no
cache
have
taken
optional
argument.
You
can
actually
provide
a
list
of
header
field
names
that
is
used
to
modify
the
semantics
of
those
directives
so,
for
example,
cache
control,
private
and
then
a
list
of
headers
means
that
you
can
actually
cache
that
in
a
shared
cache
as
long
as
those
headers
are
kept
specific
to
one
user,
so
they're
kept
private
and
and
I
pointed
out
that
this
isn't
widely
implemented.
I,
don't
think
it's
implemented
by
any
browser.
A
Roy
pointed
out
very
recently,
while
we
slept
here
in
lovely
Thailand
that
Apache
HTTP
D
implements
those
directives
and
so
I
guess
the
question
is:
if
we
have,
you
know
an
existence,
proof
that
it
has
been
implemented.
Maybe
we
should
keep
it
in
there.
Maybe
we
shouldn't,
but
I
wanted
to
get
a
sense
of
the
working
group
of
whether
people
thought
that
it
was.
You
know
in
the
in
the
last
round
of
HTTP
in
the
in
the
cache
in
spec,
we
noted
that
these
things
were
not
widely
used.
A
A
A
No
he's
he's
like
a
presenter
okay,
he
heard
me
hello,
Julie.
He
is
awake.
Good
I
love
having
to
learn
a
new
IRC
client
for
every
meeting.
Okay,
fair
enough,
so
Roy,
if
you
want
to
channel
through
ever
since
the
audio,
didn't,
seem
to
be
working
too
well
mm-hmm
I'm!
Guessing
you
would
not
like
to
change
anything
here.
Is
that
correct.
A
Correct
he
says
correct:
he
says
yeah
yeah
I,
think,
given
that
new
information
we
either
have
to
make
a
decision
to
pull
it
out
and
then
make
you
know,
Apache
non-conforming
or
leave
it
at
is
I,
don't
think
we
can
really
modify
the
language
anymore.
So
I
think
probably
close.
This
with
no
action
is
the
right
way
forward
and
are
you
gonna
record
these
names
I'm
trying
to
record
them.
A
A
Right
now,
there's
a
must
in
the
cache
and
document
that
says
that
you
must
honor
request
cache
control
directive.
So
if
a
client
sends
cache
controller
no
store,
you
have
to
honor
that
as
part
of
the
caching
algorithm
in
practice,
no
one
does
that
browser
caches,
don't
pay
attention
to
it
at
all.
Most
CD
ends
actually
probably
all
see
the
ends
by
default.
Don't
pay
attention
to
it.
A
Our
reverse
proxies,
don't
and
Ford
proxies
sometimes
do,
and
sometimes
don't,
and
so
the
suggestion
here
is
is
that
we
shouldn't
be
paying
attention
to
the
requiring
cache
implementations
to
pay
attention
to
this,
and
Roy
I
think
gave
some
feedback
again,
while
we
slept
and
I
think
I
think
yeah.
That
should
be
okay
with
him.
So
the
proposal
here
excuse
me,
is
to
downgrade
the
strength
of
request.
C
A
C
Good
David
looks
relieved
so.
A
Does
that
make
sense
to
everyone
to
not
make
this
a
firm
requirement?
They're,
just
advisory
and
Roy
I
think
was
talking
and
I
agreed
that
you
might
want
to.
We
might
want
have
some
text
about
how
it's
good,
to
have
a
cache,
be
able
to
be
put
in
a
mode
where
it
can
pay
attention
to
them,
because
in
some
cases
it
might
be
desirable,
but
it
doesn't
make
sense
to
do
this
by
default.
For
a
lot
of
folks.
A
A
So
last
time
around,
we
had
a
discussion
around
this
472
to
34,
where
the
cache
control
syntax
in
an
ideal
world.
It
would
be
generic
in
that
you
could
take
the
quoted
or
the
uncoated
form,
which
is
a
pattern
that
I
know.
Julian
especially
has
been
trying
to
pursue
in
most
of
the
specs.
But
a
lot
of
implementations
didn't
support
the
quoted
form,
and
so
we
in
72
34,
said
that.
A
Senders
should
not
generate
it
in
the
quoted
form,
but
must
accept
it,
and
what
I'm
wondering
here
in
this
issue
is:
should
we
further
codify
current
practice
and
say
you
know
you
should
not
generate
it
that
way
and
or
sorry
you
must
not
generate
that
way,
and
you
may
accept
it
and
I'm.
Seeing
on
jabber
roy
says
it
is
much
harder
to
say
that
at
the
quoted
form
is
an
error
in
validating
past
implementations
than
it
is
to
say,
should
not.
G
G
A
A
new
air
conditioner,
effectively
yeah
okay
since
you're
against
this
and
since
joins
against
this
and
I,
don't
hear
anybody
in
the
room
jumping
up
and
down
I'm
happy
to
close
this
with
no
action.
I
C
A
You
know
I
I
have
a
test
suite
both
for
browser
cache
conformance
and
for
intermediary
cache
conformance
I
can
I
forget
what
the
results
are
for
this
particular
test,
but
I
can
bring
that
information
back
and
see.
You
know
how
much
what
task
we
have
in
front
of
ourselves:
I
I,
guess
the
only
if
we
came
to
a
place
where
we
understood
that
no
cache
or
were
very
few
implementations,
supported
the
courted
form.
Then
I
could
see
you
know
making
armond
yeah.
A
A
C
A
A
So
issue
120
status
codes
and
caching,
so
in
RFC
7230
4,
we
said
that
a
response
can't
be
stored
if
the
cache
doesn't
understand
its
status
code.
So
in
other
words,
if
you
know
status
code
for
nine,
one
is
sent
to
a
cash
and
that
cash
hasn't
been
written
to
know
what
the
semantics
that
stats
could
are,
then
it
can't
store
it
on
disk,
and
we
had
I
did
a
little
digging
on
this.
We
had
a
discussion
in
the
lead-up
to
that.
A
We
said
that
there's
a
link
in
the
issue,
if
you
follow
it
to
a
discussion
of
Ã¥land
least
a
fairly
brief
one,
I
think
and
I
think
the
path
we
took
was
probably
the
wrong
one
in
that
our
current
approach
makes
it
very
hard
to
deploy
new
status
codes
that
are
cacheable.
If
I
wanted
to.
You
know,
define
a
for
nine
one
status
code
and
say
that
you
know
you
can
cache
it.
A
If
you
want
to
it's,
not
that
it's,
you
know
casual
by
default,
even
if
I
put
cache
control
headers
on
that
response
by
the
spec,
a
cache
can't
storage,
which
seems
to
add
quite
a
bit
of
friction
to
introducing
new
status
codes,
and
so
I
would
say
that
if
a
response
contains
cache
control
headers,
even
if
it's
status
code
isn't
recognized
if
by
all
other
counts,
and
we
have
a
lot
of
different
criteria.
If
that
response
can
be
cached,
why
should
the
cache
washing
the
generic
hash
Dart.
A
G
I
guess
the
problem
comes
with
the
issue
of
when
you
introduce
the
new
status
code
like
206,
which
is
likely
to
carry
cache
control
information.
That's
it's
assumed
that
the
client
understands,
in
addition
to
the
processing
required
for
206
how
where's
the
trade-off
there
I
get
I
agree
that
you
know
it's
not
ideal,
that
we
have
difficulty
caching
or
a
new
status
code
without
understanding
the
status
code,
but,
on
the
other
hand,
status
codes.
Aren't
that
frequently
updated
and
they're
pretty
much,
never
something
you
want
to
cache
to
begin
with
when
they
are
updated.
A
F
Like
Mike
Bishop,
so
I
think
the
thread
that
you
posted
convinced
me
that
we
probably
should
allow
catching
bees
and
I
think
if
we
have
something
that
shouldn't
be
catchable
like,
say
a
421
the
right
place
to
enforce.
That
is
to
say,
if
you
and
if
you
omit
the
status
code,
you
must
say
cache
control
most
or
just
explicitly
include.
A
It
on
the
server
side,
where
we
know
it's
understood.
Well,
you
wouldn't
have
to
do
that
in
that,
if
it
doesn't
have
any
caching
information
and
it's
not
known
by
the
cache
to
be
cashable
by
default,
then
the
cache
can't
store
it.
So
you
don't
have
to
make
an
explicit,
no
store,
but
what
Roy's
concerned
about
is,
if
we
have
one
of
these
weirds
test
codes
like
two
SEC's,
where
it's
it's,
you
know
carrying
metadata,
that's
intended
for
not
this
message.
A
Caching
made
it
enough
for
this
message
as
a
response
body,
but
for
a
synthetic
that
our
terminology
around
this
still
sucks
for
something
that
you're
combining
with
or
or
modifying,
and
then
it
applies
to
that,
and
that
was
the
case
in
206.
I
personally,
I
think
that
that's
probably
not
a
great
design
pattern
for
us
to
emulate
in
future
status,
guys.
G
The
important
I
was
entertained.
Caching,
information
that
had
to
be
communicated
to
the
cache.
At
the
same
time,
it
was
trying
not
to
be
cached
by
another,
otherwise
unknown
recipient.
So
it's
difficult
for
it
to
contain
something
that
says
like
no
cache.
What
I
was
thinking
is
that
you
could
define
a
new,
exciting
cache
parameter.
That
says
like
cache,
like
200
or
whatever,
where
you
can
say
that.
A
A
Yeah
I
agree
with
you
Roy
that
I
don't
want
a
bike
shed
this
or
paint
the
shed
in
the
meeting,
but
I
do
want
input
and
then
I
think
I
I
brought
this
up
for
the
same
reason
that
you
point
out,
I
would
love
to
have
other
folks
input
on
this
I.
Don't
want
it
to
just
be
me
and
Roy
and
Julian
coming
up
with
these.
A
These
terms,
you
know
we
have
this,
you
know,
what's
the
difference
in
the
headers
complete
value
and
had
her,
you
know
one
line
in
in
a
header
block
and
an
individual
that
value
and
a
list
based
header
field
and
one
thing:
I
added
which
I'd
like
to
get
some
further
input
on.
Is
you
know
it's
very
common
in
in
use
outside
this
working
group
to
just
call
it
a
header,
and
indeed
sometimes
in
this
working
group,
and
we
have
in
the
specs.
A
L
M
A
C
M
C
Sure
we
do
have
like
in
7540,
we've
got
whole
frames,
they're
just
called
headers.
The
notion
that
they
contain
a
plural
of
header
is
not
that
odd.
To
me,
you
know
and
having
like
rewritten
inspects
where
I
colloquial
refer
to
things,
those
headers
and
people
correctly,
you
know,
say
you
need
to
say
header
field
there.
C
F
F
Okay
yeah,
so
when
we
were
doing
the
editorial
pass
on
the
HQ
doc,
I
actually
wrote
on
my
whiteboard
kind
of
a
message:
header
and
body
header
fields,
at
her
block,
trying
to
figure
out
exactly
where
all
the
terminology
went.
It
makes
sense
once
you
draw
it
out,
but
it's
not
immediately
obvious.
Just
from
reading
the
box,
yeah.
A
So
I
think
we
can
do
a
cleanup
and
probably
a
you
know:
if
folks
can,
chip
in
on
the
issue
what
they
think
about,
you
know
different
proposals.
For
me,
the
high
order
bit,
and
what
makes
this
really
different
from
email
is,
is
that
no
offense,
but
it's
not
like
there
are
millions
of
developers
around
the
world
who
are
minting
and
using
male
header
fields,
I.
A
N
F
Mike
Bishop,
honestly
I
think
the
easiest
thing
to
do
is
consistency
with
the
existing
knocks,
but
maybe
for
readability
sake
and
acknowledging
that
we
will
always
slip
up
somewhere
in
some
document
is
just
to
note
that
they
are
colloquially
called
headers.
And
if
you
see
that
that's
what
it
means
well,.
C
C
L
See
I
think
there
is
actually
the
other
part
of
the
ticket
where
you
talk
about
value
or
header
fields
that
allowed
multiple
instances
or
single
instance,
which
allows
repetition.
This
is
probably
more
interesting.
The
other
one
is
more
of
a
bike
shed.
This
one
I
think
right.
It's
more
interesting
to
settle
on
some
terminology,
I
just.
A
A
A
N
So
I
think
Julianne
answered
the
question.
Well
enough,
I'm,
not
sure
that
the
document
answers
the
question
well
enough
currently,
but
I
think
that's
that's
a
part
of
what
you're
talking
about
here
might
make
the
section
make
sure
that's
very
clear
what
it,
what
what
it
means
to
reference
that
section
and
then
yeah.
L
A
Checking
for
feedback,
no,
the
jabber
channel
is
happy.
Alright,.
A
The
hetero
registry
issue
42,
we
discussed
in
dispatch,
so
we
discussed
this
in
Montreal
and
we
agreed
that
it
was
worth
having
a
chat
with
it,
but
we
needed
to
take
it
to
dispatch
I
took
it
to
dispatch.
Yesterday
there
wasn't
any
pushback
in
that
room
so
now
we're
bringing
it
back
here.
I
have
a
draft
of
how
I
think
the
registry
should
run
it's
patterned
on
how
we've
set
up
the
link.
Header
relation
sorry,
the
link
relation
registry,
as
well
as
the
well-known
URI
registry,
fairly
lightweight.
A
M
Pete
Resnick
so
I
bumped
into
a
Michelle
on
the
way
out,
and
she
said
what
what's
going
on
and
I
said:
don't
worry
about
it!
One
of
the
things
that
that
conversation,
sort
of
developed
was
separate
out
how
you
want
things
to
work
from
this
perspective
from
how
they
implemented
on
the
back
end,
because
whether
they
keep
it
all
in
one
database,
that's
viewed
separately
here.
We
don't
care
yeah,
I,
think,
but
we
want
to
have
procedures
that
we
can
input
stuff
separately.
We
don't
have
to
go
through
those
general
sure.
L
A
C
A
G
I
mean
is
that
the
that
their
registries,
that
we
have
misses
and
wraps
right
now,
if
you
look
through
them,
you'll
see
that
each
one
has
a
different
style
of
title
and
a
different
location
in
the
Ayana
database,
some
of
them
under
a
directory
related
to
HTTP
and
some
of
them
elsewhere.
It
would
be
nice
if
we
just
had
fun
HTTP
subdirectory
of
Vienna
that
you
know
had
that
consistent
set
of
titles
for
the
registries
and
I'm
wondering
if
we
should
just
do
that
editorial
Asia
as
an
instruction
for
Anna
to
fix.
L
A
Know
it's
gonna
show
this
week,
I
think,
but
in
principle,
I
think
I
agree
with
Roy
that
if,
if
we
can
harmonize
the
titles
and
the
URLs
and
then
and
that
statement
of
that,
you
know
the
framing
of
the
different
registries,
that
would
be
a
good
thing.
I,
don't
think
it'll
cause
any
harm.
As
long
as
we
have
the
proper
redirection
place.
Yes,
you.
A
And
I
was
thinking
about
whether
renaming
them
would
be
bad
or
not
and
I.
You
know
if
the
only
place
that
the
registry
name
is
gonna,
be
referenced,
is
gonna,
be
in
the
IANA
considerations,
section
of
a
document
and
if
the
documents
already
published
and
that
I
in
a
considerations
is
already
executed,
so
it
shouldn't
be
an
issue
even
if
we
rename
them
I,
don't
think.
But
let
me
talk
to
Michelle
yeah,
okay,.
C
A
F
A
A
A
Roy,
you
said,
seems
reasonable,
but
we're
at
the
top
of
the
three
accession.
Yes,
that
is
where
I
think
it
probably
should
go
at
least
until
it
looks
like
it
shouldn't
go
there.
We
put
this
in
because
we
had
the
discussion
on
the
list
about
the
confusion
around
redirects
for
certain
kinds
of
clients,
especially
in
this
case
I,
think
HLS
and
other
livestreaming,
and
and
my
takeaway
from
that
and
I
may
be
misunderstanding
things.
But
my
takeaway
from
that
was
that
the
people
reading
the
documents
were
confused
about.
A
You
know
just
because
clients
automatically
follow
redirects
doesn't
mean
that
there
is
a
an
effect
on
the
base.
Url
for
that
second
request
and
I
think
that
this
confusion
is
caused
for
the
by
the
same
phenomenon
that
we
see
sometimes
in
content
encoding
where
just
because
clients,
a
lot
of
clients
automatically
up,
you
know,
apply
content,
do
kind
of
negotiation
for
encoding
and
then
remove.
A
The
encoding
doesn't
mean
that
it's
not
a
separate
entity
that
it's
a
separate
response,
and
so,
if
we
can
clarify
that
I
think
at
the
top
of
3
xx
section
and
say
that
when
you,
you
know,
make
a
redirect.
You
know
if
it's
automatically
followed.
That's
fine,
but
you
know
things
like
the
base.
Url
and
everything
else
still
apply
for
as
a
first-class
request.
A
D
J
Just
thought
it
would
be
more
friendly
to
raise
my
hand,
it
was
a
boy
off
the
line.
I
do
not
disagree
with
the
proposed
change,
but
I
disagree
that
just
helps
in
any
way
was
the
issue
that
was
mentioned,
because
that
issue
is
just
because
the
people
did
not
understand
the
difference
between
a
URI
and
the
resource
identified
by
the
URI.
J
So
I
think
their
problem
is
very
easily
explained
that
we
need
to
find
out
why
they've
failed
to
understand
that
footing
a
URI
into
an
HTML
document
that
mean
that
document
that
the
resource
identified
by
the
URI
is
embedded
in
the
HTML
document.
That's
what
they
thought
and
that's
of
course
rubbish,
so
I'm
fine
with
adding
more
text
to
redirect
handling,
but
that
wouldn't
have
helped
them
at
all.
J
A
C
Q
So
am
orphan
German,
so
this
issue
came
up
in
the
meeting
over
streaming.
Video
Alliance,
it
seems
like
there
are
multiple
issues
with
many
many
clients
not
following
in
or
not
following
a
direct.
That's
that's
a
different
issue,
but
not
properly
resolving
relative
references
that
is
being
read
from
playlist
or
the
manifest
files
after
redirect
and
from
talking
with
different
Syrians
and
and
that's
using
HTTP
redirect
for
CDN
for
video
is,
is
very
commonly
used
and
talking
with
several
phidian's.
Q
It
seems
that
they
had
a
lot
of
issues
with
different
clients
and,
most
of
the
time
when
trying
to
resolve
that
client,
the
software
developers
are
just
saying
that
they
are
following
the
RFC
as
it
is,
and
the
problem
is
with
the
RFC
and
not
with
their
implementation.
And
that's
what
we
are
trying
to
resolve
here
is
to
understand
what
what
is
the
correct
understanding
of
how
you
resolve
reference
relative
references
from
the
thread
and
especially
from
the
inputs
from
Julian.
Q
It
seems
that,
after
when
a
manifest
for
or
an
MPD
file
is
being
requested
through
a
URI,
it
doesn't
really
matter.
Where
do
your
I
came
from
because
the
URI
itself
is
the
file
the
manifest
file
base?
Uri
is
the
retrieval
URI
and
then
anything
that
comes
afterwards
should
result
according
to
that.
So
if
that's
the
case,
I
think
that
some
clarification
either
in
the
original
HTTP
or
through
our
document,
could
be
in
place
and
then
we
can
start
working
working
with
our
players,
software
to
fix
it.
G
G
G
So
as
appealing
as
it
might
be
to
add
more
text
about
that
to
the
HCP
RFC
it
doesn't.
Actually,
we
don't
actually
define
that
behavior.
It's
part
of
the
way
how
your
eyes
are
defined,
but
we
can
still
add
additional
information
to
the
spec
explaining
how
we
expect
redirects
to
work.
But
the
issue
of
what
is
the
base
URL,
that's
already
handled
by
the
other
specs.
C
Yeah
speaking
individually,
ie
I
agree,
that's
true,
but
in
the
name
of
readability
you
know
when
this
issue
came
up,
you
know
I'm,
like
oh
I,
just
need
to
cite
and
then
like
I
had
a
20-minute
slot
conversation
with
mark
trying
to
figure
out
what
to
cite
so
I
think
you
know
a
little
annotation
here
of
you
know.
You
know
no
must
level
language
or
anything
we're
just
a
little
helpful
information.
You
might
I'd
give
us
more
consistent
implementations,
which
is
what
we're
going
for
here
with
core
right.
So.
J
J
Arm
the
issue
that
was
raised
here,
what
happened?
What's
fly
without
any
redirect
as
well,
because
the
confusion
is
about
what
is
the
base
URI
for
the
content
of
a
manifest
file
reference
from
HTML?
So
even
if
there
is
no
redirect,
that
would
be
confusion
about
that
unless
you
realized
that
that
it's
the
URL
of
the
manifest
file.
J
So
the
issue
is
about
whether
something
that
your
reference
from
an
HTML
page
is
embedded
or
not,
and
it's
not
embedded.
If
it's
only
the
you're
right,
it
would
be
embedded.
It
would
if
it
would
be
a
data
of
your
life.
But
that
is
not
the
case
here.
So
adding
text
to
redirect
is
can't
help
but
wouldn't
solve
this
issue.
P
A
A
So
Roy
commented
again:
whilst
we
slept
I
just
looked:
oh
it's
pretty
clear
that
location
is
a
URI
reference.
Anything
else
is
not
interoperable.
The
problem
with
double
hash
and
redirects
is
because
it
isn't
allowed
in
ER
a
reference
and
is
commonly
removed
for
interrupt,
not
just
by
browsers
the
other
wiki
concerns
were
already
addressed
by
the
last
revision.
A
A
E
G
G
G
Reporting
system
was
that
that,
in
fact,
a
piece
of
soccer
that
uses
a
double
hash
sign
forage
for
its
identifier
doesn't
work
very
well,
because
one
of
the
hash
hashes
across
hatcheries
is
by
the
internal
software
within
the
referencing
of
this,
both
the
browser
and
the
reason
it
does.
That
is
because,
historically,
the
euros
have
never
allowed
more
than
one
hash
in
the
string.
It
was
a
very
fixed,
hard
requirement.
It
goes
way
way
back
to
two
Timbers,
these
original
drafts.
G
A
So
I
will
attempt
channel
on
ax,
which
is
an
interesting
experience.
I
think
that
that
the
reasoning
here
is
that,
because
location
headers
are
arguably
under
control
of
a
broader
set
of
authors,
all
I
think
that's
may
be
debatable.
You
need
to
have
better
more
crisply
to
find
error,
handling
and
URL
offers
that.
A
A
A
Think
the
most
I
could
personally
justify
would
be
referencing
the
URL
standard,
not
normatively,
but
informatively
and
say
by
the
way,
there's
this
thing
over
here.
That
tells
you
how
to
do
their
handling
if
you're
interested
but
I,
don't
hear
anybody
supporting
that
I
see
some
shrugging
shoulders.
That's
that's
progress.
I.
G
We
want
to
add
location
header
that
says
how
we
should
deal
with
vectors
that
are
not
allowed
in
the
your
I
reference,
a
bayonet.
You
know,
that's
fine,
that's
that's!
Just
a
normal
error
handling
I'm,
just
saying,
as
as
a
the
grammar,
the
grammar
that
we
use
is
okay.
If
you
follow
this
grammar,
it's
going
to
be
an
interoperable,
that's
the
intent
of
the
interoperable
standards.
If
you
stay
within
the
grammar
you're
good,
but
if
you
go
outside
the
grammar,
it
doesn't
mean
that
you
didn't
receive
the
characters.
F
A
If
you're
familiar
with
what
working
group
respects
they,
they
use
an
algorithmic
approach,
it's
a
specification.
So
it's
quite
detailed
in
terms
of
do
this.
Do
that
and
you
know
you
get
into
this
state
and
so
forth,
and
so
on.
Yeah.
F
A
So
this
has
come
up
in
a
couple
different
ways.
Is
there
support
for
adding
a
bit
of
text
about
error,
handling
for
a
location,
URLs
and
I?
Think
when
we
started
the
core
work?
One
of
the
things
we
said
we
would
look
at
is
when
something
has
security
or
interoperability
impact,
but
especially
security
impact.
We'd.
Look
at
tightening
up
things
like
error
handling
to
make
sure
that
that
we
meet
again
at
that
and
I
think
there's
an
assertion.
I,
don't
know
that
Donna's
made
this
assertion
in
the
past.
C
Here's
one
that
for
a
resolution
drafted
and
see
if
this
captures
what
we've
been
talking
about.
Maybe
people
can
comment
on
that
this
proposal
isn't
compatible
beyond
browser
scope.
Uri
reference
is
required,
however,
to
do
add
some
non
normative
advice
about
the
grammar
and
error
handling,
noting
that
you
still.
A
N
A
A
A
A
N
O
O
A
N
A
A
A
I,
don't
know-
maybe
maybe
I
put
it
in
there
just
because
we
use
it
in
things
like
media
types
is
a
kind
of
an
escape
valve,
but
maybe
we
don't
need
it.
I.
A
Plus
it's
the
new
X
thanks
for
that
fields.
That
begin
with
HTTP,
we
should
disallow
that's
a
good
point.
Roy
and
I'm,
wondering
I
I
think
maybe
one
of
the
reasons
I
kept
this
open
was.
If
we
want
to
go
one
step
further,
we
could
require
field
names
to
start
with
a
digit
or
alpha
not
allow
them
to
start
with
a
or
or
a
period.
N
A
A
N
J
N
P
A
C
J
A
Think
it
would
be
confusing
if
we
constrain
the
registry,
but
didn't
have
reflected
in
the
BNF
I.
Think
that
a
lot
of
the
value
of
doing
this
would
be
lost
because
people
would
not
clearly
understand
you
know
what
the
guide
rails
for
the
syntax
we're
putting
down
are
I
think
that
when
we
use
a
B
and
F
in
our
documents,
that
is
what
we
are
documenting
as
something
that
is
safe
to
generate
and
that
people
who
generate
other
things
won't
be
interoperable.
A
P
N
Ya,
lentils
and
the
the
concern
here
is
that
if
someone
rejects
the
entire
message
based
on
the
presence
of
a
header
field,
that
has
one
that
say
it
has
a
plus
character
in
it.
They
reject
the
entire
message.
As
a
result,
that's
that's
likely
going
to
cause
some
surprises
and
interoperability
concerns
or
worse
for
adapting
the
one
header
hurry
so
removing
that
header
from
from
that
particular
message
is
not
necessarily
a
problem,
because,
if
you
weren't
expecting
to
handle
that
anyway,
it's
that's
just
normal
I'm,
more
concerned
about
the
sort
of
collateral
effects.
Sure.
A
N
A
C
But
this
is
suggestion
that
plus
perhaps
could
result
in
shutting
down
of
connections,
which
you
know
maybe
and
wider
used
in
the
people
in
this
room.
You
know
are
aware:
I
mean
I'm
firmly
in
favor
that
you
know
the
the
registry
should
reflect
best
practices.
Here.
It
seems
concerning
to
overreach
that
hi
I.
A
J
R
C
A
A
F
G
Just
explain
it
in
the
a
beam
app
as
well
that
that
well,
there
are
a
couple
different
ways:
you
can
do
it.
You
have
ever
Cindy
baby.
Now,
that's
different
from
the
setting
may
be
enough,
but
that's
not
really
very
satisfying
you're.
Generally
speaking,
you
don't
have
any
control
over
what
you
receive.
So
what
you
really
want
is
a
a
an
a
B
enough
to
just
specify,
what's
the
correct
thing
to
send
and
then
on
the
receive
side,
how
do
you
deal
with
errors?
G
And
in
this
case,
in
most
cases,
most
software
should
already
be
removing
certain
characters
from
the
header
fields
received
before
they
go
out
to
a
gateway,
but
when
what
may
not
be
occurring
is
the
header
fields
that
are
handled
by
is,
for
example,
custom,
HTTP,
servers
or
modules
that
don't
have
a
need
to
go
out
to
a
gateway.
You
can
be
processed
directly
yeah
effectively.
They
don't
really
need
any
of
these
requirements.
These
requirements
are
aren't
necessary
for
them.
C
N
First
of
all,
what
do
implementations
do
in
the
presence
of
characters
outside
of
the
norm
that
they
lose
the
message
to
they
lose
the
that
particular
line
or
what
and
then
what
characters
are
actually
used
in
practice,
and
some
of
us
may
have
the
ability
to
measure
those
sorts
of
things.
I
don't
know.
Is
it.
A
A
After
some
recent
experiences
of
graphs
I'm
very
interested
in
that
little
world
I'm
wondering
and
again
with
traffic,
you
know
we
can
look
at
traces
for
a
bunch
of
web
traffic
and
then
suddenly
you
look
at
traces,
for
you
know,
people
doing
API
stuff
in
the
backend
and
spawned
some
corporate
firewall
and
you're
gonna
see
something
very
different,
I'm
wondering
if
we
can
maybe
just
change
the
a
B
and
F
to
deprecated
some
range
of
characters
and
then
say
that
you
know
implementation
handling.
Those
characters
is
its
implementation,
specific.
A
A
O
C
C
O
C
C
A
Guess
does
the
change
in
degree,
because
if
we
look
at
eventually
the
current
set
of
characters
that
are
allowed
field
name
equals
token
and
token
includes
dollar
sign
percents
ampersands
single
quotes,
star
tilde
type
I
mean
it's
a
pretty
broad
set
of
characters.
Do
we
really
want
to?
Let
you
know
it's
any
V
care
except
the
limiters.
Basically.
A
C
A
All
right,
maybe
a
little
data,
would
help
I
think,
maybe
not
the
not.
You
know
what
is
the
set
of
things
that
is
done
by
all
implementations,
but
if
we
can
find
examples
of
characters
that
cause
interoperability,
problems
that
might
help
move
things
forward.
S
John
phonetics
on
the
registry
point
you
mentioned
yesterday
in
dispatch
that
it
was
a
expert
review
so
sound.
That
sounds
to
me
like
a
situation
where
somebody's
registering
something
the
expert
can
say.
Do
you
really
need
to
have
this
grid
character?
If
the
answer
is
yes,
because
we're
using
it,
that's
okay,
but
the
expert
can
say:
maybe
you
should
try
to
you
know
if
you're
not
already
using
it.
You'll
have
a
pain
point
here
so
much
you
might
try
something
else.
All
right.
It
sounds
like
you
know.
The
advantage
of
expert
review
is
a
lets.
A
And
I
guess
I'm
not
as
interested
in
the
registry
approach
here,
because
from
me
the
goal.
The
reason
this
is
interesting
to
talk
about
is
that
if
we
can
give
a
target
to
things
like
laughs
and
other
bits
of
software,
that
you
know
can
reject
or
or
strip
headers
based
upon,
knowing
that
you
know
characters
that
would
be
I
think
a
good
thing,
but
maybe
it's
it's
it's
not
something
we
can
do.
A
A
As
Brad
says
in
the
issue,
the
HTTP
RFC
is
say
nothing
about.
The
expectations
are
in
half
closed,
TCP
connections
in
practice,
HP
clients
don't
shut
down
there,
they're
half
of
things
after
sending
a
request,
but
it
would
be
nice
to
infer
some
semantics
from
that.
Wise
media,
Sogeti,
okay
and
so
I
think
the
suggestion
here,
if
you
scroll
down.
A
Joseph
made
a
case
before
trying
to
infer
some
semantics
from
you
know,
incoming
Finn
as
an
indication
of
clients,
loss
of
interests,
because
then
the
server
can
free
up
resources
earlier
and
the
savings
are
more
pronounced
when
done
with
responses
at
trickle
information
down
slowly,
for
example,
long
polling
and
then
talking
about
you
know
so,
advantages
for
firewalls
doing
net
and
stuff,
or
rather
interactions
with
them.
I
think
Roy
pushed
back
on
that.
So
let's
have
this
discussion.
A
A
T
N
One
Thompson
one
of
the
recent
changes
in
TLS
was
that
we
recognized
that
half-closed
was
thing
and
tell
us
one
3includes
text
on
this
and
I
think
implementations
of
implement
but
important
that
having
implemented
that
implemented
across
all
versions
of
TLS.
So
we
have,
we
can
say
similar
things
about
TCP
and
TLS.
N
G
N
C
C
What
has
usually
happened
is
the
client
has
sent
a
fin
and
dropped
out
of
the
NAT
table,
and
now
you
send
a
response
and
you
sit
there
for
a
very
long
time,
timing
out
on
the
TCP
thing,
and
that
is
by
far
and
practices
what
is
happening
much
much
more
than
an
actual
half-closed,
which,
as
far
as
I,
can
tell
no
one
actually
does
so.
It
creates
an
operational
problem
to
support
this
half-closed
semantics
that
no
one's
really
trying
to
use
that's
kind
of
the
issue.
F
Mike
Bishop
kind
of
going
to
Roy's
question
of
layering
I
just
want
to
share
where
I
have
encountered
this
issue
before,
which
is
that
and
Microsoft's
server-side
implementation.
There
was
a
bug
that
was
incorrectly
considering
the
client
to
have
gone
away
when
the
incoming
connection
was
half
closed
and
then
aged
to
layer.
You
was
looking
at
a
stream
instead
of
a
TCP
connection
and
at
the
end
of
the
request,
the
stream
was
half
closed,
and
so
there
was
an
application
that
was
actually
checking.
Is
the
client
still
there
and
the
answer
was
no?
K
C
That
isn't
the
only
case
right,
but
it's
gonna,
be
you
know.
If
your
application
just
went
away,
will
normally
generate
a
reset
if
everything
it's
like
fully
and
then
connected,
but
it
turns
out
like
a
lot
of
times
when
you
go
away,
you're,
not
fully
and
and
connected
anymore.
So
I'm
not
sure
if
there's
a
v4
v6
distinction
or
not
in
the
data
but.
H
Suppose
anger,
I'm
kind
of
curious
about
the
use
case
for
this,
and
since
that
it
seems
like
this
could
be
done
with.
If
you
wanted
to
actually
close
the
connection,
you
could
do
it
with
connection
close
as
well.
If
you
really
wanted
to
like
get
rid
of
the
connection
after
the
first
request
was
finished,
processing
and
modern
clients
were
like
we
use,
connections
and
stuff.
C
I
mean
if
you
have
a
lot
of
evidence
of
that
placate
of
clients
like
intentionally
trying
to
use
half
clothes
for
the
you
know
for
for
the
case.
That,
like
makes
logical
sense
to
us,
but
like
haven't
really
seen
in
the
field
that
would
be
interesting
to
know
like
you've
got
an
application
that
does
a
lot
of
half-clothed
David's
Ganassi
Google.
U
Eric
Kinnear
Apple
I
want
a
second.
What
Mike
is
saying
is
like
this
makes
some
sense
for
HP
one,
but
now,
as
we
start
talking
about
the
later
versions,
where
you
have
the
ability
to
say,
stop
I'm
not
interested
in
the
response
anymore
and
things
are
intentionally
half-closed
a
lot
of
the
time.
It's
worrisome
to
conflate
those
issues
for
people,
because
you
don't
always
know
what
this
is
running
over
and
that
could
have
some
really
painful
and
intended
consequences.
U
F
If
you
see
the
client
has
half
closed
after
the
request-
and
you
say
that's
equivalent
to
sending
connection
close
and
the
server
should
not
expect
to
receive
any
more
data
and
should
close
the
connection
after
it
sends
the
response.
That's
entirely
consistent
and
that's
good
what
the
server
should
not
do
and
what
I
think
this
issue
was
originally
raised
is
assume.
The
client
does
not
want
the
response
and
either
terminate
partway
through
the
response
or
just
not
send
a
response.
That
I
think
is
actively
harmful
to
some
plans,
which.
C
So
I'm
interested
in
that
so
I
mean
I,
think
I,
agree,
I,
mean
I.
Think
the
basis
of
this
issue
is
that
pretend
or
not
pretending,
but
acting
with
no
impact
of
receiving
the
half-closed
in
reality,
is
more
indicative
of
the
client
having
gone
away
than
the
client
just
not
intending
to
send
any
more
data
right,
despite
I
mean
I
agree.
That's
not
like
the
literal
interpretation
of
what
it
should
mean,
and
so
I
would
like
to
close
this
issue
with
you.
F
A
A
A
T
V
C
A
As
a
good
editor
should
see
the
applicable
requirement
in
sixty
seven
sixty
one
is
applications
that
do
not
implement
torch
protocol
should
generate
an
error
on
the
use
of
onion
onion,
but
should
not
perform
a
DNS
lookup
and
that's
to
preserve
the
privacy
characteristics
of
people.
People
using
onion
don't
want
those
DNS
requests
escaping
out
to
the
resolver.
R
A
R
K
Authority
and
I'll
point
out
that
the
IAB
invited
people
who
were
considering
such
things
to
put
them
under
DARPA,
so
whether
they
might
not
be
in
the
top-level
domains
anymore.
Similar
things
might
be
minted
under
DARPA
after
that
invitation
was
extended.
So
I
actually
think
that
that
Pete's
suggestion
that
making
this
advice
about
checking
to
see
what
special
use
names
are
currently
registered
and
treating
them
so
that
they
are
not
presented
to
the
DNS
does
seem
to
me
like
a
reasonable
sweet
spot.
Okay,.
R
It's
Ganassi
just
thinking
on
the
way
back
to
going
sit
it
down.
I'm
gonna
completely
contradict
what
I
just
said.
Sorry,
sixty
seven
sixty
one
puts
requirements
on
like
DNS
clients
and
technically
HTTP.
Isn't
your
most
HTTP
clients
today
call
into
some
DNS
function?
Maybe
it
could
be
implemented
in
the
browser
or
someone
else
do,
but
it's
kind
of
a
separate
sub
module
and
it's
up
to
that
component
to
check
this.
R
A
C
So
I
think
you
know
bright
mentions
a
security
consideration.
I
think
we
might
be
able
to
say
that
there
are
some
application
requirements
that
apply
to
HTTP
those
are
defined.
You
know
by
DNS
such
as
sixty
seven
sixty
one
right
to
get
you
aware
of
things
like
the
locals
things,
I
mean
the
the
data
onions
back
was
written
thinking
of
HTTP
pH.
A
A
A
A
D
From
gondwana
this
is,
this
is
something
that
came
up
just
a
few
weeks
ago.
Cal
connects
that
we
ran
into
issue
where
you
would
put
a
record,
and
you
might
say
either.
This
is
the
value
of
it
right
now,
but
it's
just
about
to
change,
because
the
server
needs
to
make
some
changes
to
it
or
the
server
might
not
make
the
changes.
So
we
had
to
reply
with
a
wiki
tag,
because
we
don't
know
immediately
whether
it's
going
to
schedule
straight
away
I'm
something
we're
interested
in
knowing
what
gets
done
here.
A
So,
at
least
for
what
I
talk
about
in
the
issue
here,
I
think
to
do
something
here.
We
need
to
create
an
implicit
relationship
between
the
strong
and
weak
version
of
one
attack
so
that
they
wouldn't
be
considered
two
completely
independent
things,
but
you
know
you
could
upgrade
from
one
of
the
other.
Is
there
interest
in
trying
to
do
that.
D
P
D
A
You
know
I,
don't
bring
something.
Here's
the
current
term
has
always
been
a
body
that
is
being
written
on
what.
G
I
might
exerted
everything
for
the
week
II
eat.
Eggs
was
that
you
didn't
want
to
get
stuck
with
a
half
half
correct
body
forever,
because
if
you
received
it
and
it
changed
within
the
same
sex
whatever
that
you
received
it,
that
you
might
get
stuck
with
a
bad
body
and
but
honestly,
the
reality
is
that
that
folks
have
just
ignored
that
over
time
and
would
rather
deal
with
the
one-in-a-million
chance
of
getting
a
an
override
error
like
that.
Then
not
have
decent
magic.
A
A
One
is
really
interesting
because
there's
a
header
called
content
security
policy
yay,
so
there's
a
case
where
a
customer
generates
content
security
policy
headers
using,
for
example,
the
Apache
HDX
s,
mod,
headers
and
Apache
would
not
send
that
header
because
it
ops
it
out
were
fixing
that
and
reverse
proxies
would
not
update
it
on
the
304
and
so
they'd
serve
the
old
content
security
policy.
Header
trying
to
get
that
fixed
and
browsers
would
ignore
the
content
security
policy
header.
If
it
ever
made
it
in
a
304
to
the
browser.
A
I,
don't
know
how
to
fix
that
and
I
don't
know
if
we
need
to
start
advising
people
not
to
use
three
or
fours
or
something
else,
but
it
seems
like
it's
a
concerning
situation.
So,
if
folks
are
interested
in
this,
please
come
talk
to
me.
I'm
gonna
top
some
browser
folks
about
it
and
try
and
figure
out
where
I
need
to
go
with
it.
But
I
did
I
considered
a
security
issue
mostly
because
of
content
security
policy.
Is
there
a
core
issue
open
github?
Is
you
know
coming.
C
A
No
I'll
get
one
open,
I.
Think
at
the
very
least,
we
need
to
talk
about
what
headers
get
exempted
from
a
update
in
3
or
4
and
I.
Think
it's.
You
know,
h1
connection
headers,
like
you,
know,
connection
and
keep
alive
and
stuff,
but
then
the
question
of,
if
brow,
if
proxies,
aren't
going
to
update
headers
on
disk,
where
do
we
go
from
there
they've
had
years
and
years
and
years
to
do
it?
They
still
don't
do
it
a
lot
of
them?
I,
don't
know
how
to
help
that
issue,
and
the
other
thing
is
Marie.
C
Before
mirga's
that
I
just
want
to
close
sort
of
the
loop
on
core
and
specifically
I
want
to
thank
mark
Julian
and
Roy
for
the
tremendous
amount
of
work
we
devoted
a
whole
session
to
this
today
and
I
know
it's
not
as
exciting
as
Thursday's.
Agenda
of
you
know,
shiny
new
new
things,
but
this
is
important
work
we're
going
to
be
left
with
this
document
for
a
long
time,
because
I
for
one
have
no
interest
in
reopening
it
again,
so
they
put
out
a
new
set
of
drafts
for
this
meeting.
C
If
you
haven't
like
read
the
drafts
yours
file
on
github,
it
would
be
great
to
take
you
know
a
read-through
of
these
of
the
state.
The
hope
is
by
the
time
we
meet
again
in
Prague
that
we
were,
you
know,
really
talking
about
just
a
very
few
things
at
the
end.
So
this
is
really
the
right
window
where
you
should
pay
attention.
If
you
haven't
done
a
clean
read
through
knowing
that
these
will
be
the
definitive
citations
of
the
semantic
layer
hgp
for
the
rest
of
your
career,
you.
D
V
Murray
good
morning,
my
name
is
Murray
COO,
Charlie
and
I'm,
working
on
with
some
folks
at
Facebook
and
indirectly
elsewhere,
to
collect
some
of
the
security
considerations
that
have
to
do
with
compression
dictionaries,
which
is
a
topic
that
keeps
coming
up
coming
up
each
time
it's
been
approached
I.
Guess
we
get.
We
go
through
some
spasms
about
a
way.
V
We
have
to
make
sure
we
do
this
safely
and
securely
and
make
sure
that
when
this
comes
through,
all
of
these
potential
security
issues
have
been
addressed
and
whoever
proposes
the
work
eventually
backs
off
and
so
I'd
rather
collect
all
that
information
into
one
place.
So
we
can
run
it
as
a
checklist,
essentially
so
that
when
someone
has
a
dictionary,
the
compression
dictionary
thing
to
bring
forward
they've
gone
through
this.
So
they
can
see
this
collected
wisdom
and
applied
it
appropriately.
V
So
I
volunteered
to
do
an
informational
document
collects
all
of
that
and
do
it
for
the
working
group.
I
spoke
to
Nick
Sullivan
on
during
the
hackathon,
and
he
said
he
would
be
happy
to
contribute.
The
folks
back
at
Facebook
are
willing
to
contribute.
So
if
anybody
has
something
wanna
make
sure
they
see
in
this
document,
please
let
me
know
and
I
guess:
I
can
post
a
draft.
That's
marked
for
this
working
group
and
you
can
do
a
call,
ideally
to
just
send
it.
How
how
would
you
like
me
to
do
it
a
usual
way?