►
From YouTube: IETF110-WPACK-20210312-1430
Description
WPACK meeting session at IETF110
2021/03/12 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Sean
is
about
to
get
us
started
as
soon
as
he
activates
his
mic,
but
I
wanted
to
hop
in
real
quickly
and
say
thanks
to
chris
lemons
for
being
our
notetaker
awesome.
Thank
you
very.
B
Much
yeah
hey
welcome
to
wpac.
We
didn't
meet
last
time.
This
time
I
figured
we
might
as
well.
Do
it
and
try
to
spin
stuff
up
and
get
things
restarted,
so
here's
the
kind
of
it's
the
end
of
the
week,
so
hopefully
you've
seen
these
before.
If
you're
just
tuning
us
we're
going
to
do
a
little
little
bit
of
updates
about
its
process
stuff.
B
Basically,
the
reason
why
we
have
your
video
turned
off
because
we
don't
want
to
crush
the
servers
if
you're
going
to
talk,
feel
free
to
turn
them
on,
as
I
will
now
so
you
can
see
my
face
and
my
ever-growing
beard
the
mean
echo
link
is
there
obviously
the
audio
only
and
the
code
emd
notes
are
there
and
that's
where
chris
is
going
to
be
taking
notes
for
us
note
d
well
again,
hopefully,
you've
been
around
this
week
and
you've
seen
this
before.
B
Basically
ipr
rules,
if
you're
going
to
participate,
you
need
to
kind
of
understand
what
they
are.
If
you
know
something
say
something
also,
we
have
a
code
of
conduct,
so
let's
keep
it
professional.
If
you
have
any
questions
about
any
of
these,
you
can
ask
the
chairs
francisca,
who
is
our
responsible
area
director?
She
and
murray,
did
a
little
bit
of
a
chair
swap
or
any
of
the
other
people
that
you
see
in
the
list
on
the
left
that
you
might
have
seen
around
a
lot
at
a
lot
of
the
other
meetings.
B
We're
perfectly
willing
to
answer
those
questions
again,
we're
at
wpac.
It's
only
one
more
session
after
this.
If
this
is
not
the
right
place,
though
there
are
other
sessions
going
on
myself
and
dave.
Are
the
chairs
agenda
pretty
simple
this?
B
We
have
one
topic
today,
which
is
basically
about
trying
to
get
us
to
adopt
the
bundle
format
document
as
a
starting
point.
It
is
definitely
not
the
thing.
That's
done.
It's
going
to
take
some
time
to
review
it,
and
so
people
have
to.
You
know,
consider
that
when
we
get
to
the
point
where
we're
trying
to
figure
out
what
we're
going
to
do
with
it,
does
there
anybody
that
wants
to
bash
the
agenda
to
add
anything.
B
C
Cool
yeah,
having
you
run,
the
slides
is
great.
A
C
I
am
happy
to
take
interruptions.
Okay,
I
should
have.
We
should
have
plenty
of
time
to
get
through
the
slides.
Yes,
so
I'm
jeffrey
eskin.
I
use
him
pronouns
and
I
will
be
describing
the
the
current
draft
of
the
bundle
format
in
the
hopes
that
we
can
decide
to
adopt
it
at
this
meeting
next
slide.
C
C
C
The
format
has
an
invariant
bit,
it
has
sections
and-
and
it
ends
with
the
total
length
which
allows
using
it
in
in
things
like
self-extracting
executables,
and
then
it
defines
the
the
set
of
sections
that
kind
of
every
implementation
would
would
implement,
and
then
we
can
add
extra
sections
in
in
extension
documents
and
it
has
a
security
consideration
section
next.
C
Slide
so
the
the
overall
semantics
are
that
a
bundle
is
a
set
of
http
representations.
Those
representations
are
themselves
represented
by
http
response
messages,
plus
information
from
the
index
representations
are
named
by
urls
and
content
for
content
negotiation
information,
but
in
a
later
slide,
there's
a
proposal
to
change
that
next
slide.
C
So
bundles
are
have
two
kind
of
modes
that
they
can
operate
in.
One
is
stored
on
a
random
access,
disk
or
sd
card,
or
something
and
for
those
you
have
to
load
the
index
to
start
reading
anything.
And
then
you
go
straight
to
the
resource
bytes.
C
You
can
also
stream
a
bundle,
there's
two
kind
of
notions
of
streaming
or
two
aspects
of
streaming
stream
generation.
So
if
the
sender
doesn't
have
the
whole
thing
before
it
wants
to
start
serving
a
request,
it
needs
to
know
all
the
resource
sizes
before
it
starts
sending
anything.
C
C
C
C
The
core
sections
that
are
defined
in
this
document
are
the
index,
which
gives
a
map
from
the
name
of
the
response
to
the
the
byte
range
in
the
responses
section,
so
that
enables
random
access
there's
a
manifest
url,
which
could
point
to
something
like
an
app
manifest
for
things
on
the
web.
Epub
has
a
manifest
document.
C
C
C
So
daniel
ehrenberg
has
submitted
a
couple
prs
to
mostly
remove
things
from
the
the
initial
draft,
and
I
wanted
to
get
the
sense
of
the
the
working
group,
the
sense
of
the
working
group
about
whether
to
include
or
reject
those
prs
for
the
purposes
of
adopting
the
document.
We
can
change
our
minds
later,
as
the
document
evolves.
So
don't
feel
like
this
is
your
your
last
chance
to
accept
these
pr's
or
we
can
undo
our
decision.
C
If,
if
we
take
a
pr
and
decide,
we
should
re-add
one
of
the
things
that
removed
next
slide.
C
The
the
motivation
for
these
changes
and
and
daniel
can
can
jump
in
if,
if
I
get
anything
wrong
or
answer
more
questions,
if
people
want
more
details,
the
the
current
draft
supports
both
vote,
using
a
bundle
to
represent
sub-resources
resources
of
a
page
and
using
it
to
represent
kind
of
a
whole
page
all
at
once,
like
as
the
top
level
resource.
C
It
appears
that
sub-resource
loading
needs
fewer
features
than
loading
as
a
whole
page,
and
there
are
more
questions
about
whether
whether
all
browsers
will
or
all
clients
will
support
loading,
a
top-level
page
for
bundle
and
so
he's
proposing
to
remove
the
things
that
aren't
needed
for
resource
loading.
C
D
Okay,
cool
so
just
to
elaborate
a
little
bit
on
the
motivation.
If
you
want
to
go
back
to
the
previous
slide,
I'm
I'm
really
focusing
on
making
sure
that
that
bundling
is
consistent
with
with
the
needs
of
content
blockers,
because
if
this
is
going
to
be
on
the
web,
there's
a
lot
of
different
things
that
user
agents
do.
D
D
Whereas
some
of
these
other
features,
it's
not
clear
how
how
they
would
how
they
would
fit
together.
So
I
wanted
to
to
sort
of
focus
on
the
the
agreeable
parts
first
and
yeah.
I
guess
we
can
talk
more
about
details
later.
E
F
I
like
the
fact
that,
when
you
mute
non-mute,
someone
else
is
talking,
there's
a
gap,
so
I
missed
my
name
there,
but
I
I
think
this
is
the
right
sort
of
thing
to
be
trying
to
think
about
right
now
it
was.
It
was
good
to
see
in
the
early
designs
how
you
had
a
fairly
maximal
design,
but
when
it
comes
to
getting
it
done,
a
very
narrowly
targeted
small
thing
is
is
more
likely
to
be
successful
here.
F
One
of
the
things
that
I
was
thinking
in
terms
of
you
know
if,
if
we
get
this
wrong,
for
instance,
if
perhaps
one
of
these
cuts
cuts
a
little
too
deep,
there's
always
the
opportunity
of
defining
another
format
with
a
different
mind
type,
something
like
that,
and
that
gives
us
a
pretty
big
escape
hatch.
So
I'm
not
worried
about
really
cutting
severely
unless
we
have
an
immediate
use
case
for
the
feature,
and
that
particularly
relates
to
the
critical
thing.
C
Right-
and
we
can-
we
still
have
some
time
between
adopting
the
document
and
publishing
it
that
we
can
also
change
our
minds.
F
The
other
thing
that
I
wanted
to
briefly
ask
before
you
get
into
all
of
these
other
things
is
if
you
could
talk
a
little
bit
about
the
the
current
state
of
thinking
with
respect
to
the
integration
of
this
into
the
into
the
rest
of
the
the
ecosystem,
because
there's
been
a
lot
of
discussion
about
that,
many
words
have
been
spilled
on
github
markdown
and
I
have
not
been
able
to
read
all
of
them
and
so
just
getting
a
brief
couple
of
minute
overview
on.
That
would
be
pretty
helpful.
F
Yeah,
probably
more
in
the
client's
behavior
sort
of
thing.
So
how
would
I,
how
would
I
expect
to
use
one
of
these
bundles
and
how
would
I
expect
to
pull
things
out
of
them
primarily.
C
Right
so
a
lot
of
that
is
still
up
in
the
air.
I
know
you
wrote
a
blog
post
with
a
suggestion
that
looks
quite
plausible
right
right
now,.
C
Yeah
chrome
is
working
on
an
origin
trial
that
that
loads
things
in
a
kind
of
less
less
cautious
way.
The
the
origin
trial,
which
runs
from
chrome
90,
which
is
releasing
soon
to
chrome,
92,
allows
you
to
to
use
a
link.
L
equals
funnel
to
say
view
this
bundle
for
sub
resources
within
the
current
page
and
then
things
anything
in
the
bundle
kind
of
intercepts
stuff
that
the
page,
loaded
or
page
asks
to
load.
C
The
likely
eventual
answer
is
that
we'll
have
some
sort
of
some
sort
of
fetch
map
or
loading
loading
map.
That
declares
like
this
bundle
is
used
for,
or
has
these
entry
points
and
then
those
requests
from
the
page
are
intercepted
by
the
bundle.
Other
things
are
are
probably
not
intercepted
by
the
bundle,
and
then
the
bundle
can
have
internal
references
of
some
sort
to
say.
C
If
I,
if
I
name
this
url,
it
comes
back
to
me,
I
think
there's
still
there's
still
an
open
question
of
kind
of
exactly
how
the
bundle
does
that,
like
we
in
the
in
the
chrome
origin,
trial,
there's
a
way
to
load
an
iframe
from
a
bundle,
but
the
url
of
the
iframe
is
is
provided
by
something
else
in
the
bundle
and
so
the
something
else
in
the
bundle
has
to
has
to
be
able
to
say
make
sure
to
to
load
this
iframe
from
me.
C
I
I
suspect
we
can.
We
can
make
that
work,
but
it's
not
all
figured
out
yet.
F
Yeah,
so
I
think
the
piece
that
would
be
missing
for
people
listening
along
here
was
the
fetch
maps
concept,
which
is
essentially
this
idea
where
you
embed
in
in
the
web
page
a
map
that
says
when
I
provide
this
url
reinterpret
that
to
mean
this
other
url,
and
so
the
browser
will
then
take
all
references
to
this
resource
that
it
sees
and
replace
it
with
a
reference
to
another
resource,
and
that
allows
you
to
do
things
like
0.2
things
inside
bundles,
for
instance,
and
it
also
allows
for
a
bunch
of
other
use
cases
in
terms
of
managing
your
content.
F
But
I
think
that's
critical,
so
it's
I'll!
Let
you
get
on
with
it
now,
thanks
for
indulging
that.
A
D
Yeah,
I
want
to
articulate
an
intermediate
step
between
these
two
things:
atomically
loading,
the
whole
bundle
and
this
whole
fetch
fetch
map
with
dependencies,
and
this
is
something
that
I
I
was
hoping
to
have
prepared
in
time
for
this
meeting
but
haven't
yet,
which
is
that
you,
you
have
a
bundle
which
contains
the
the
client
asks
for
a
list
of
assets
that
are
expected
to
be
contained
in
the
bundle,
but
it
only
fetches
particular
subsets
as
as
needed.
I
think
this
is.
D
This
is
really
important
for
loading
performance
in
a
way
that
when
you,
when
you
have
a
large
application
which
is
split
into
several
sub-resources
and
they
may
be
already
loaded
or
maybe
attached,
then
it
can
be
important
to
to
do
this
kind
of
incremental
loading.
I
think
I
mean
I
would.
I
would
like
to
come
back
to
this
group
for
more
feedback
on
this
kind
of
intermediate
proposal,
but
it's
not
it's
not
fully
fleshed
out
yet.
C
The
integration
of
bundle
fetching
with
the
http
cache
is
also
not
fully
worked
out.
We
we
think
that
we
can
make
them
interact
well,
but
we're
we
haven't
actually
like
written
everything
down.
C
C
This
happens
because
for
sub
resource
loading
there
isn't
a
particular
primary
url,
and
so
the
the
current
draft
says
leave
it
empty
it.
It
becomes
more
important
for
top
level
documents
where,
if
you
don't
understand,
if,
if
the
client
doesn't
understand
the
bundle,
there
is
a
fallback
it
could,
it
could
redirect
somewhere
and-
and
so
we
like
it
is.
It
is
plausible
to
move
this
to
a
section,
but
it
means
that
clients
just
fail
when
they
get
a
bundle.
C
They
don't
understand
instead
of
being
able
to
recover.
C
I
can
I
can
take
any
discussion
on
this
now
or
we
could
go
through
everything
and
then
come
back
and
go
through
and
and
kind
of
take
take
homes
for
for
whether
to
to
accept
these
or
reject
them.
For
the
for
the
initial
adopted
version.
F
Hi,
so
in
in
this
case,
here
you
you're
imagining
that
if
you
have
a
primary
url,
there
would
be
a
specific
type
of
section
that
would
contain
this
information.
Is
there
any
ordering
requirements
you're
talking
about.
C
There
is
not
a
particular
ordering
requirement,
although
if
you've,
if
you
request
a
bundle
or
try
to
load
a
bundle
and
the
and
the
client
wants
to
use
the
primary
url
to
pick
which
resource
out
of
it
to
load
as
a
result,
then
you
have
to
wait
for
the
primary
url
to
be
received
before
you
can
actually
load
that
resource.
F
Right
but
you
don't
you,
don't
necessarily
have
any
any
structural
constraints
that
would
force
it
to
be
any
in
a
particular
place,
and
it's
just
it
in
this
case
it
would
be
just
a
a
section
that
is
what
annotated
differently
or
is
it
a
different
type
of
section?
I
I'm
trying
to
understand
what
what
special
behavior
you're
attributing
to
this,
as
opposed
to
just
having
this
as
metadata.
D
I
think
the
different
use
cases
of
bundles
have
quite
different
semantics
for
what
this
primary
or
fallback
url
would
would
mean,
differs
a
lot
from
you
know,
an
an
epub.
You
know
future
publishing
thing
from
something
in
which
case
I'm
not.
D
We
have
these
these
things
about
fallback
semantics,
but
I
think
what
fallback
means
differs
a
lot
based
on
how
something
is
is
deployed,
and
so
I'm
this
is.
This
is
a
major
reason
why
I
think
it
really
makes
sense
to
separate
this
so
given
that
index
is
not
forced
to
be
in
a
particular
place
linearly
in
the
sections,
I
think
it
makes
sense
to
also
not
have
this
requirement
for
the
primary
fallback
url.
D
I
know
I
don't
think
it
would
be
bad
to
create
such
a
restriction,
though,
if
you
look
at
webassembly's
binary
format,
they
have
a
similar
architecture
with
section
names,
but
they
currently
have
restriction
on
the
ordering
of
sections
and
they're.
Considering
relaxing
that,
but
it's
you
know,
they're
just
lots
of
valid
points
of
the
design
space
here.
D
So
one
thing.
A
I'd
like
to
just
make
a
quick
note
that
we
seem
to
be
discussing
this
now,
as
though
this
is
already
a
working
group
adopted
item,
and
now
we
are
re
refining
the
document
and
it's
a
very
interesting
discussion.
But
I'm
wondering
if
we
should
maybe
focus
on
whether
you
see
this
as
being
fundamentally
at
odds
with
adopting
this
as
an
item
to
work
on.
F
If
that's
how
you
want
to
roll
this,
then
maybe
we
should
just
go
through
the
items
one
just
briefly
and
we
we
can
avoid
discussing
them.
I
I
think
this
is
a
reasonable
thing,
but
oh.
A
Oh,
I
I
agree,
it's
a
very
engaging
conversation.
I
I
think
it
is
entirely
reasonable.
One
of
our
main
objectives
in
this
session,
though,
was
to
identify
whether
we
had
a
document
that
was
ready
to
be
adopted
and
worked
on
by
the
working
group,
and
I
was
just
feeling
at
the
moment
like
we're
already
working
on.
It
has
always
been
adopted.
C
C
Online
use
cases
will
almost
certainly
negotiate
for
the
bundle
as
a
whole.
It
is
really
inefficient
to
send
two
copies
of
a
resource
when
you're,
when
you're
actually
sending
it
over
a
network,
so
so
online
use
cases,
especially
including
the
sub
resource
loading
use
case
will
probably
not
actually
use
the
content
negotiation
information
in
the
current
format.
It
costs
one
or
two
bytes
per
resource
to
kind
of
support,
content
negotiation
if
you're
not
using
it.
C
So
it's
not
a
very
expensive
thing
to
support,
but
it
it
does
cost
some
implementation
complexity
and
so
there's
a
there's,
a
suggestion
to
remove
that.
From
the
from
the
current
version,
it
would
be
possible
to
add
a
a
different
section
type
that
then
re
re-adds
it,
but
the
question
of
whether,
like
whether
we
will
actually
wind
up
using
content
negotiation
at
all
is,
I
think,
an
interesting
one,
even
even
for
offline
use
cases.
C
C
C
It's
of
course
inefficient
to
to
actually
collide
with
the
critical
section,
because
it
means
that
you,
you
have
to
kind
of
fall
back
in
some
way
or
fail,
feel
the
load
in
any
online
case.
But
it's
also
hard
to
add
this
later,
because
we
need
kind
of
earlier
implementations
to
reject
things
with
with
sections.
They
don't
understand.
So
I
I
would
prefer
not
to
not
to
take
this
pull
request,
but
I
I
want
to
leave
it
up
to
the
working
group.
C
I
think
that's
the
last
the
last
slide,
and
so
then
we
can
discuss
whether
which
of
these
to
accept
for
the
purpose
of
adopting
the
draft,
and
then
we
can
discuss
the
content
of
them
and
kind
of
whether
to
whether
to
do
them
after
adopting
the
draft
or
whether
to
undo
them.
After
adopting
the.
B
A
Sure
we're
just
gonna
use
the
hand
tool
to
do
a
basic
show
and
we're
gonna
ask
in
the
affirmative
first:
should
we
adopt
this
draft
as
a
should
be
formally
as
a
working
group
document,
and
so
you
should
be
able
to
pop
over
to
the
hand
and
raise
your
hand
if
you
indeed
think
that
this
is
a
good
starting
point
for
the
the
work
of
the
charter
of
the
group
within
in
line
with
the
charter
of
the
group,
I
mean
to
say-
and
I
will
also
ask
again
after
this
really
quickly
to
see
if
there's
any
I'll,
ask
the
negative
to
see
whether
there's
objections
to
working
with
this.
A
We
have
a
few
buzzed
in
oh
francesca,
is
our
a.d
is
stepping
in
to.
B
A
But
I
I
will
say
that
so
far
the
sense
of
the
room
is
pretty
clearly
in
favor
a
couple
of
people
elected
not
to
raise
their
hand,
but
that's
not
necessarily
an
objection,
and
but
I'm
gonna
end
the
poll
right
now.
12
people
raised
their
hand
to
didn't
raise
out
of
the
27
participants.
Of
course,
there's
some
double
counting
and
the
number
of
participants
that
are
represented.
A
So
do
you
want
more?
Do
you
to.
A
And
if
you
want
to
affirmatively
say
you
have
no
ejections,
you
can
click
explicitly
that
do
not
raise
hand.
A
A
Okay,
so
far,
we
have
nine
with
no
objections
and
and
and
zero
objecting,
so
we're
going
to
take
that
as
a
positive
result
to
bring
back
to
the
list
to
formalize
the
adoption.
A
Sean
back
to
you
or
perhaps
back
to
jeffrey
now,
because
we
have
time
in
the
session
to
discuss
the
other
issues
in
the
document.
If
we
want
to.
B
C
One
one
note
that
we
discussed
kind
of
offline
is
that
I
am
planning
to
rename
the
draft
to
wpac
bundled
responses,
because
it's
no
longer
about
exchanges.
We
figured
out
how
to
kind
of
represent
everything
as
hp
response
messages.
A
Okay,
thank
you
jeffrey
dkg,.
H
Please
hi
there
I'm
relaying
p
snyder
from
jabber
who
is
unable
to
dial
in.
H
H
I
know
jy
and
mt
have
both
have
found
these
concerns
either
mistaken
or
a
cost
worth
the
benefit
from
the
proposal
or
similar.
I
don't
mean
to
relitigate
that
here,
but
I
wanted
to
re-note
that
the
folks
most
invested
in
are
concerned
with
content.
Blocking
are
the
folks
who
have
raised
the
loudest
concerns.
Some
of
the
previously
noted
rejections
or
responses
to
those
concerns
are
from
vendors,
who
do
relatively
less
content
blocking
in
their
products.
A
Thank
you
dkg
and
I'm
p
sniper
martin
thompson,
please.
Actually.
I
was
personally
quite
happy
with
bolton
martin
and
daniel
in
their
three-way
conversation.
Before
I'm
sorry,
I
interrupted
the
flow
we
had
an
objective
to
get
to
but
daniel.
If
you
want
to
jump
in
and
continue
this
kind
of
round
table,
you
were
having
works
for
me.
D
D
People
is
mentioning
this,
this
content
blocking
concerns,
and
one
aspect
of
those
concerns
was
about
whether
it's
appropriate
to
have
a
bundle
to
be
representing
a
full
page
on
the
web,
as
if
the
bundling
would
be
would
sort
of
take
over
how
how
websites
work
and
make
them
this.
This
one
big
opaque
item,
which
differs
from
from
some
resource
loading,
which
is
maybe
more
granular,
and
this
also
relates
to
the
subsetting.
D
D
D
A
F
So
I
I
wanted
to
just
make
sure
that
it
was.
It
was
fairly
clear
here.
This
is
a
starting
point
to
all
those
involved.
This
is
this
is
just.
G
F
We
start
the
journey
and
I
think
pete
and
others
have
registered
this
this
concern,
and
I
think
there
is
some
potential
risk
here
that
we
do
something
very
bad
for
those
sorts
of.
F
There
are
risks
and
we
could
potentially
design
something,
that's
very
very
bad
for
those
particular
use
cases,
but
I
think
we
need
to
make
sure
that
we
we
work
through
all
of
those
things,
there's
probably
a
bunch
of
other
things
in
this
list
that
are
also
similarly
bad
for
various
other
reasons.
I
noticed
php
earlier
mentioned,
having
indexes
at
the
end,
so
it'd
be
easier
to
change
the
contents
of
of
bundles
things.
Things
like
that.
A
And
I'll
also
just
read
in
pete
snyder's
comment
for
the
record.
I
think
it
is
a
core
for
the
sub
resource
loading
that
is
great
and
being
able
to
split.
The
sub-resource
case
from
the
document
case
seems.
A
Valuable,
would
you
like
to
have
any
more
discussion
on
issues
now
or,
if
there's
no
more
feedback,
we
can
take
it
to
the
list
for
further
work.
G
C
Then,
just
as
as
kind
of
the
the
source
for
the
initial
working
draft
working
group
draft
so
right,
how
do
how
do
people
feel
about
about
moving
the
it
becomes
a
primary
url?
If
we
put
it
in
a
section,
it
can't
really
be
used
for
fallback.
F
F
So
if
you
imagine
that
a
bundle
represents
a
book,
if
you
have
an
ebook
reader,
maybe
it
has
one
entry
point.
If
you
have
a
phone
that
maybe
it
has
a
different
entry
point
and
if
you're
using
a
desktop
browser,
maybe
it
has
a
different
entry
point
again,
and
so
you
can
imagine
having
different
labels
or
annotations
on
on
resources
that
allow
someone
to
to
pick
the
one
that
suits
them
best.
I
don't
know
whether
this
is
metadata
for
the
individual
resources
in
the
in
the
bundle
or
whether
it
is
sections.
C
My
feeling
is
that
one,
the
way
that
you
represent
metadata
is
in
a
particular
named
section,
and
we
just
defined
that
that
section
contains
certain
metadata.
C
The
the
reason
to
have
a
primary
url
is,
when
you
kind
of
navigate
to
the
bundle
itself,
and
you
want
to
know
what
to
load
and
so
something
that
dispatches
based
on,
like
the
the
client
form
factor
or
whatever
could
could
be
represented
inside
of
that
that
primary
resource
or
it
could
be
done
as
as
kind
of
a
section
with
with
a
map
itself.
I
think
those
are
those
are
reasonably
equivalent.
C
The
only
thing
we
lose
by
by
moving
this
to
a
section
is
that
it
can't
be
used
for
fallback
and-
and
I
agree
with
daniel-
that
that's
not
necessary
for
sub
resources,
where
you
have
a
public
url
anyway,
that
you're
just
replacing
with
the
bundle
if
the
bundle
doesn't
load.
You
you
just
net
load
the
resource
from
the
network.
F
Yeah,
I
guess
this
goes
back
to
the
question
of
of
what
we
believe
the
the
referencing
infrastructure
to
look
like,
and
so,
if
you
imagine
that
the
referencing
infrastructure
provides
a
link
to
a
non-bundled
resource
or
a
bundled
resource,
then
you
already
have
that
that
fallback
built
in
at
the
at
the
next
layer
up.
You
don't
have
to
worry
about
dealing
with
bundles
in
order
to
get
the
capability.
C
Eventually,
I
think
I
would
like
a
hum
for
this
like
whether
to
accept
this
pr
just
to
like
get
confirmation
from
the
room,
but
it
feels
like
we're
leaning
toward
accepting
it.
C
B
D
I
wanted
to
mention
that
my
intention
for
this,
for
factoring
it
into
a
separate
section,
was
also
to
take
a
second
step
and
say
well,
actually,
this
moves
to
some
other
document.
The
way
that
you
know
the
other
things
that
I'm
proposing,
removing
it's
not
removing
forever,
just
it
could
move
to
some
other
some
other
document.
So
I
think
that
the
the.
D
You
know
it's
adopting
this
or
merging
this
pr.
We
might
consider
that
follow-on
work
or
or
not
depending
you
know,
it's
a
separate
question.
A
Okay,
thank
you
daniel
the
poll
is
up
and
so
far
extremely
lightly
attended.
We
have
only
two
people
registering
anything.
F
C
I
I
think
that
the
fallback
url
is
useful
and
putting
it
in
the
core
format,
costs
very
little
and
and
supports
some
longer
term
work.
But
I
don't
feel
super
strongly.
A
And
I
will
say,
because
we
shouldn't
let
the
hum
drag
on
for
too
long,
that
overall,
it
was
a
very
quiet,
positive
hum.
A
There
only
seven
people
actively
clicked
a
button
at
all
and
and
five
of
them
were
saying,
go
ahead
and
merge
it.
So
it's
not
a
vote,
but
it
is
weekly
in
favor
of
going
ahead
with.
A
C
Sorry,
let's
go
to
the
next
slide:
yeah.
C
Okay,
removing
content
negotiation.
It
is
a
it
is
some
implementation,
complexity,
a
fight
or
two
per
resource
in
size
and
probably
not
not
used
for
sub-resource
loading
but
likely
used
for
some
of
the
offline
cases
that
we
hope
to
support
in
the
long
term.
Please
discuss.
D
Yeah,
I
think
this
makes
sense
out
of
if,
if
you're
thinking
about
some
resource
loading,
it's
the
online
case,
it
seems
quite
strange
to
to
think
through
how
the
semantics
would
would
work
at
runtime.
It
seems
to
add
more
more
complexity
to
the
subresource
loading
case
would
have
to
handle.
D
You
have
to
decide
what
to
do
when
there's
bundles
that
have
these
multiple
representations
and
what
to
to
put
in
in
cash
the
for
the
content
blocking
story.
I
think
this
really
comes
back
to
separating
bundling
for
sub
resource
loading
versus
separating
versus
bundling
for
for
whole
websites.
The
content
blocking
case
makes
more
sense
in
in
whole
websites,
and
I
don't
know
if
that
is
valuable
as
a
thing
for
web
browsers
to
load
online
offline
usage
by
things
that
are
not
general
purpose.
Web
browsers,
I
think,
is
a
separate
question.
A
Oh,
thank
you,
I'm
not
sure
daniel,
just
kind
of
abruptly
dropped.
Martin,
please.
F
This
one's
difficult
for
me,
because
I
can
immediately
see
the
value
of
having
things
like
multiple
languages
or
those
cases
where
you
have
multiple
different
image
sizes
for
the
different
form
factors
that
that
are
involved
actually,
that
one's
not
a
great
example,
I
think
think
about
it
again,
but
having,
for
example,
all
of
the
different
css
that
you
would
require
for
display
on
small
screens
and
large
screens
and
and
whatnot
rather
than
the
customized
single
user
agent
single
form
factor
css.
That
is
often
delivered
in
web
cases.
The
online
cases.
F
So
I'm
kind
of
on
the
fence
with
this
one
again
I'll,
probably
ask
jeffrey.
But
why
would
you
what
specific
reasons
would
you
give
for
keeping
it.
C
There's
there's
one
other
more
speculative
one
that
I
didn't
list
on
the
slide,
which
is
that
in
cases
where,
where
the
server
would
check
at
one
of
the
say,
sec,
fetch,
headers,
saying
and
and
wants
to
constrain
how
resources
are
used,
you
can
you
can
use
or
or
maybe,
abuse,
content
negotiation
to
say
like
if,
if
sec
fetch
dust
is
is
such
and
such
then
the
resource
exists
and
otherwise
it
doesn't
and
and
actually
like
use
that
to
block
inappropriate
use
from
within
the
bundle.
C
F
Which,
which
also
makes
me
wonder
whether
we
have
an
answer
to
the
question
of,
can
we
do
cause
with
with
bundles,
but
as
the
implicit
thing
is,
it's
a
get
request
for
the
for
the
url
that's
listed,
I
don't
think
that's
possible,
which
sort
of
cuts
a
lot
of
those
scenarios
out.
We,
you
could
say,
okay,
here's
my
bundle,
content
and
it
is
available
for
reading
by
these
other
origins
as
well
as
this
current
one.
That's
not
something
that's
possible
in
this
format,
either.
D
And
I
don't
understand
the
course
point.
You
have
response
headers
right.
What
do
request
headers
have
to
do.
I
mean
how
does
that.
F
D
Great,
so
I
wanted
to
mention
that
I
previously
proposed
that
we
have
the
normal
index
section,
which
would
be
without
content,
negotiation
and
then
a
separate
negotiated
index
section.
That
would
be
more
more
optional,
that
you
would
use
for
your
subset
of
resources
that
you
actually
wanted
to
do
content
negotiation
on.
So
you
could
have
a
basic
bundle
which
has
nothing
negotiated,
and
then
this
advanced
bundle
format
which
has
this
the
second
index.
So
that
adds
some
complexity
versus
saying
that
there's
always
content
negotiation.
D
C
I'm
not
a
huge
fan
of
having
kind
of
of
doing
it
with
two
different
section
types
because
which
which
one
does
the
server
send.
It
definitely
shouldn't
send
both
because
that
wastes
a
bunch
of
space,
but
but
daniel
isn't
right
that
we
can
do
it
that
way.
A
C
Oh
and
pete
pete
wrote
in
the
in
the
jabber
that
removing
content
negotiation
is
important
to
him.
First,
it
makes
it
more
likely
that
we'll
maintain
benefits
of
content
blocking
because
we're
less
likely
to
fetch
multiple
versions
of
the
same
resource
and
two
it
makes
personalization
less
likely,
although
not
impossible.
C
I
don't
follow
really
either
of
those,
but
that
is
what
he
wrote.
B
Hey
so
what's
kind
of
emerging
in
the
in
the
chat
room,
I
think,
is
that
what
we
may
end
up
doing
actually
is
just
adopting
the
04
version
of
this
draft
or
making
that
the
actual
call
for
adoption
and
getting
it
in,
and
then
we
can
use
these
pr's
as
like
the
first.
B
B
It's
fine
with
me:
it
works
for
me
all
right
cool.
I
mean
at
some
sense
it
makes
it.
It
wakes
makes
it
much
easier
for
me
because
now
there's
not
a
gating
function,
it
might
make
me
look
better
if
he
takes
a
week
so
that
I
can
get
the
github
repo
up,
but
I
have
a
funny
suspicion
that
he
can
hit
the
merge
button
faster
and
I
can
get
the
repo
set
up.
C
F
That's
one
thing
that
if
we
put
that
one
to
bed,
one
thing
that
occurred
to
me
on
this
content
negotiation
thing
is.
F
When
I
was
thinking
about
the
image
case,
in
particular
that
that
does
sort
of
lead
me
to
to
think
that,
perhaps
we
don't
really
need
content
negotiation
for
the
purposes
of
having
multiple
images
and
whatnot.
So
one
of
the
one
of
the
original
problems
with
the
personalization
aspects
of
of
bundling
was
that
you
either
had
to
provide
all
the
variants
of
a
particular
image
say.
F
You
know
the
high
dpi
version
of
the
image
and
the
little
thumbnail
for
the
small
screen,
but
then
you're
just
using
up
all
the
bits
for
all
of
the,
although
it's
the
confidence
or
real
explosion
there,
whereas
you
might
as
well
just
send
all
of
the
bits
for
the
really
high
res
thing
and
just
have
the
the
client
downscale,
because
it's
had
to
download
the
bits
anyway.
It
doesn't
have
a
lot
of
choice
in
the
offline
case.
F
F
I
do
sort
of
wonder
whether
there
are
options
available
to
someone
who
who
takes
who
doesn't
have
content
negotiation
available
to
them.
That
would
would
still
work.
In
that
scenario.
It
just
means
structural
differences.
So,
rather
than
serving
the
same
page,
that's
got
to
vary
based
on
except
language
which,
for
various
reasons
I
don't
like
anyway,
the
the
site
says
I'm
going
to
serve
the
same
content
to
everyone
and
write
some
script.
F
That
says,
if
the,
if
the
native
language
is
english
well,
we
can
we'll
pull
up
the
english
translation
or
what
have
you
it's
not
as
easy,
but
it
certainly
makes
the
the
overall
format
much
much
easier
to
reason
about.
A
C
Since,
since
we'll
be
taking
these
for
the
the
working
group
draft
01
taking
them
or
not,
I
think
it
would
still
be
useful
to
get
the
hum
on
kind
of
whether
the
working
group
wants
to
adopt
them.
A
A
The
I
probably
should
have
said
that
audibly
for
people
who
are
listening,
but
not
necessarily
looking
the
the
poll
the
hand
tool,
was
active
right
now
to
chime
in
on
this
pr.
A
Mp
is
added
his
hand
in.
A
A
So
I
think
I'm
I
think
I'm
I'm
going
to
have
to
say
that
that
probably
warrants
further
discussion
on
the
list.
C
Okay,
do
we
move
the
manifest
section
out
of
the
out
of
the
core
document
and
into
an
extension
document
that
we
would
we
would
adopt
separately?
Manifest
section
is
already
optional.
Things
don't
have
to
things,
don't
have
to
include
it
in
a.
A
F
And
sort
of
discussion,
yeah
say
something,
so
I
I
think
a
manifesto
is
another
type
of
top
level
thing
that
you
might
want
to
go.
Looking
for
and
again,
the
question
comes
down
to
whether
you
have
a
dedicated
section
for
this
thing
or
whether
you
have
an
individual
resource,
that's
annotated
as
as
being
a
manifest.
F
Those
are
the
things
that
I
think
is
I'd
like
to
pursue
rather
than
having.
This
is
where
the
manifest
exists,
and
then
that
gives
you
some
flexibility
in
terms
of
what
your
manifest
actually
looks
like,
because
the
manifest
that
a
web
browser
looks
for
the
wave
application
manifest,
which
is
a
json
file,
probably
looks
a
little
different
than
the
sort
of
thing
that,
let's
just
say,
the
java
jar
file
executor
runs
if
people
were
crazy
enough
to
port
that
to
using
a
format
like
this,
it
might
actually
work
by
the
way,
but.
C
And
so
you're
saying
that
we
should
move
this
out
of
the
core
so
that
we
can
define
different
section
names
for
for
the
different
kinds
of
manifests.
F
C
Current
the
current
design
says
you
give
a
url
and
then
you
content
negotiate
for
the
one
you
want
and
if
we
pull
content
negotiation
out,
then
of
course
that
doesn't
work
right.
B
Running
up
into
the
time
constraints
of
our
hour
session,
so
I
think
what
we're
gonna
do
is
take
these
these
two
removals,
because
there's
this
one
with
that
and
the
removal
of
the
critical
section
to
the
list
and
we'll
start
that
after
we
get
the
working
group
draft
in
the
in
the
doors
that
sound
like
a
way
forward.
D
Would
folks
be
interested
in
an
interim
session
to
discuss
this
as
well
as
sub-resource
loading
details,
you're
still
you're,
stealing
my
thunder
man.
That
was
my
next.
B
Point
so
I'm
hoping
that
we
can
try
to
set
up
after
we
get
to
working
group
after
we
do
the
working
group,
adoption
call
and
the
repo
set
up
and
stuff
that
we
actually
try
to
have
an
interim
I'm
not
thinking
weeks,
I'm
thinking
like
a
month
month
and
a
half
away
so
that
people
have
got
some
time
to.
You
know,
get
motivated
and
do
some
stuff
and
then
try
to
have
an
interim
again.
I
think
we
should
take
this
to
the
list,
but
I
was
definitely
thinking
the
same
thing.
Daniel.
B
So,
in
the
parting
shot
of
a
minute,
let
me
see
how
you
start
a
session
interested
in
an
interim.
Let's
start,
it
start
one
of
those
little
polls.
You
can
jump
over
there
and
throw
your
hand
up
or
down
and
see
how
it
goes.
I
think
I'll
still
take
it
to
the
list.
I
guess
the
other
thing
is
thanks
for
your
time,
thanks
for
taking
notes
chris
all
right.
B
Well,
we
got
you
know
eight
runners,
one
no
raise
hand,
so
you
know,
I
think,
if
we
had
10
people
that
were
active
that
showed
up
to
an
interim.
I
would
be
ecstatic
so
thanks
thanks
for
that,
thanks
for
your
participation,
thanks
for
dave
for
running
us,
the
show
here,
let's
do
it
and
we'll
see
you
all
on
the
internet,
bye.