►
From YouTube: IETF111-WPACK-20210726-2130
Description
WPACK meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
Oh,
I
am,
we
need
a
note
taker.
Please
looking
down
the
list,
I
I
see
one
particular
person.
I
would
be
inclined
to
call
out
as
a
known
quantity
of
previously
good
help,
but
it's
always
great
to
hear
some
volunteers.
B
All
right
and
with
that
out
of
the
way,
let's
get
cranking,
welcome
to
wpac
at
iatf
111..
Just
to
note,
we
are
recording
this
session.
Please
meet
your
microphone
unless
you're
speaking
and
it's
good
to
use
a
headset
to
maybe
get
some
of
the
noise
canceling
things.
Obviously
you're
here
you
found
the
medeco
link
for
those
who
are
in
other
lands.
There
are
some
links
down
there.
B
The
notes
are
also
the
kodi
md
down
there
at
the
bottom
feel
free
to
get
there
and
help
braun
and
others
fill
those
in
all
right.
So
this
is
the
second
session
of
the
its
a
pretty
strong
possibility.
You
have
not
seen
this
yeah
if
this
is
your
first
session,
so
please
know
well
that
if
you're
participating
in
the
ietf
you're
gonna
abide
by
the
process
and
policies,
those
cover
a
lot
of
things
first
and
foremost,
is
if
you're
aware
of
a
patent
or
patent
applications
and
you're
going
to
participate.
B
That
means
speak.
Write.
Do
anything
of
that
sort!
You
need
to
disclose
those
we
can
help.
You
figure
out
how
to
do
that.
If
you
do
not
know
how
you
also
acknowledge
that
you're
gonna,
your
written
audio,
video
and
photographic
records
will
be
made
public
again.
This
meeting
is
being
recorded
note
that
we
also
want
everybody
to
kind
of
keep
it
professional.
B
B
Is
pretty
straightforward?
We're
gonna
go
through
most
of
this
we've
already
done:
they've
virtualized
or
automatic
automized
to
the
virtual
blue
sheet.
So
we're
good
to
go
there.
We
have
a
note
taker.
We
do
not
have
a
jabber
scribe
yeah
if
anybody's
in
java
feel
thanks
for
doing
that,
we're
going
to
be.
A
B
B
Great,
so
we're
really
got
two
topics:
one
is
the
use
case
status
and
the
other
one
is
the
bundle
we
did
get
some
slides
from
felipe.
I
wasn't
sure
if
I
was
gonna
get
some
from
jeffrey,
so
I
threw
him
in
there.
It
shouldn't
be
ten
minutes,
it's
gonna
be
the
rest
of
the
session.
B
So
unless
anybody
has
any
agenda
bashing
they'd
like
to
do
we're
going
to
kind
of
just
jump
into
the
use
case
discussion,
we
do
not
have
slides,
we'll
just
have
a
general
discussion
about
it.
Any
bashing.
B
Okay
sold
so
in
terms
of
the
use
case
document,
we
did
a
working
group
call
for
adoption
and
we
got
only
a
couple
of
responses.
Obviously
the
author
was
like
sure
I'll
do
the
work.
We
got
one
person,
I
think
that
kind
of
indirectly
said
they
really
think
they
need
it,
and
we
got
two
people
that
were
like.
B
We
don't
really
think
that
we
need
to
do
this
document,
so
we
checked
with
our
id
and
whether
or
not
we
were
required
to
do
this
and
confirmed
what
I
think
david-
and
I
knew
is
that
it's
not
really
necessary
that
we
actually
produce
a
use
case
document,
but
francesco
would
like
to
have
the
use
cases
at
least
documented
somewhere.
B
So
you
know,
we've
got
the
document
going,
that
kind
of
doesn't
need
to
be
adopted,
and
so
it
can
be
edited
if,
if
need
be,
but
we
can
also
do
you
know
emails
to
keep
track
of
all
these
things.
So
as
long
as
we
can
point
to
them
and
provide
input
to
francesca
that
she
knows
that
what
we're
addressing
with
our
particular
protocol,
we
could
be
good
to
go.
A
This
rick,
please
speak.
D
Hi,
so
I
wasn't
really
aware
that
webpack
was
happening,
but
something
caught
my
eye,
because
I'm
one
of
the
co-chairs
of
the
dtn
working
group,
where,
of
course
we
do
lots
of
work
with
bundles.
So
I
was,
I
spotted
the
word
bundle
and
and
followed
the
links
through
to
this
agenda
so
use
case.
A
Yeah
specifically,
we
do
like
it
as
kind
of
the
background
substrate
for
why
the
working
group
is
doing
what
it's
doing,
but
it
doesn't
have
to
become
an
rfc.
D
B
We
hear
you
and
there
was
see
there-
was
no
intention
to
actually
ever
publish
this
document
as
as
a
you
know,
as
an
rfc,
we
were
just
going
to
use
it
in
the
working
group
and
lots
of
other
working
groups
struggled
with
this
right.
It's
like
well,
you
got
to
document
this
thing
to
make
sure
you're
doing
the
full
engineering
approach,
and
then
you
know
it
either
gets
published.
B
It
gets
published
before
the
protocol
goes
out
the
door
and
then
it's
wrong
and
the
protocol
needs
to
correct
the
document
or
the
use
case
document
gets
changed
at
the
very
end
to
make
sure
it
lines
up
with
the
protocol.
So
it's
like
all
right,
so
I
don't
know
I
just
want
to
throw
it
out
there.
So
thank
you.
D
E
Hello
yeah,
I
just
I've
heard
you
were
saying
that
you
can
possibly
work
on
it
without
adopting
it.
This
just
sounds
bizarre.
If
it's
not
adopted,
then
the
working
group
has
no
control
over
it.
So
there
is
no
consensus
that
it
represents
anything
discussed
in
the
working
group,
so
my
suggestion
would
be
adopt
it,
but
just
not
publish
it
as
an
rfc.
F
A
Okay
yeah
thank
thank
you
alexi.
I
I
hear
what
you're
saying
there
got
kind
of
the
the
minimal
adoption
effort
approach:
troll
yeah
martin,
please.
G
If
we
adopt
something
like
this,
that
means
we're
going
to
need
to
reach
consensus
on
things
and
there's
a
lot
in
that
document
that
I
find
actionable
and
some
things
that
I
think
are
quite
good
and
it's
a
mix
and
I
don't
really
want
to
go
through
the
effort
of
litigating
every
single
one
of
those
points.
That's
a
lot
of
work.
A
H
A
E
H
I
was
just
gonna,
I
commented
in
the
chat
already,
but
the
the
working
group,
the
webpack
working
group,
has
gone
back
and
forth
over
a
bunch
of
different
use
cases
in
the
past,
and
some
of
them
have
been
explicitly
decided
to
be
put
aside,
so
he
could
focus
on
others,
and
I
regret
I
have
not
followed
the
latest
discussions
closely
enough
to
know
specifically
what's
in
and
out
of
scope,
but
even
just
knowing
what
is
being
ruled
out
of
scope
is
something
concretely
useful
for
people
who
are
trying
to
review
this
stuff,
as
it
goes.
H
F
Ted,
hardly
speaking
thanks
very
much.
I
just
wanted
to
go
back
to
the
point
that
martin
was
making.
I
have
a
strong
suspicion
that
if
you
object
to
some
of
the
elements
of
this
document,
if
there
are
protocol,
features
that
are
motivated
by
them
later
and
you
object
to
those
will
then
end
up
in
the
same
place
of
saying.
F
But
in
the
meantime
that
means
we
can
separate
the
litigation
about
what
use
cases
rightly
should
motivate
protocol
features
from
discussion
of
the
technology
to
achieve
them,
and
I
I
really
kind
of
think
that
that's
going
to
end
up
being
better,
it
may
not
be
faster.
I
don't
think
anything
is
going
to
be
faster
honestly
between
those
two,
but
I
think
it's
at
least
cleaner,
and
that's
why
I
would
suggest
going
that
way.
Thanks.
I
I
wanted
to
comment
on
on
dkg's
comment
that
there's
there's
a
bunch
of
use
cases
in
the
use
cases
document
that
are
kind
of
part
of
the
long-term
vision
and
like
we
should.
We
should
discuss
them
or
discuss
whether
we
want
to
keep
the
long-term
vision.
I
The
current
focus
is
on
the
subset
of
those
use
cases
that
have
more
consensus
and
felipe's
doing
a
really
good
job
and
and
we'll
be
talking
about
the
attempt
to
focus
the
kind
of
core
draft
one
of
the
use
cases
that
have
more
consensus,
and
I
think
we
don't
absolutely
have
to
to
get
around
to
discussing
the
more
controversial
use
cases
until
we
get
done
until
we
finish
with
the
more
core,
less
controversial
pieces,
except,
I
suppose,
in
the
cases
where
we're
designing
flexibility
into
the
format,
to
support
the
controversial
stuff
and
people
might
want
to
remove
that
flexibility.
G
Then
we
sort
of
force
the
discussion
about
the
the
difficult
ones
to
the
foreground
and
thus
far
we
had
managed
to
avoid
that.
I
would
like
to
concentrate
on
the
the
very
narrow
thing
that
philippe
going
to
be
talking
about.
I
think
that
would
be
a
constructive
use
of
our
time.
I
don't
think
pursuing
this
would
be
a
constructive
use
of
outline.
A
So
I'm
joining
the
queue
here
as
no
hat,
because
this
is
definitely
not
a
chair
opinion,
but
just
a
radio
participant
part
opinion
in
that.
I
personally
would
like
to
see
a
being
able
to
clarify
exactly
why
we
are
adopting
the
protocol
we're
doing
to
address
the
use
case
that
we're
addressing,
and
so
I
basically
I'm
looking
at
a
hybrid
of
what's
been
discussed.
A
J
B
So,
thank
you,
yeah.
I
think
what
we're
getting
to
is
that
jeffrey?
Can
we
spin
the
use
case
document
to
only
include
ones
that
we
think
essentially
are
accepted
and
then
be
able
to
move
that
one
forward
and
put
the
rest
of
them
in
an
appendix
to
say,
like
you
know
too
controversial,
or
you
know,
you
know
just
fyi
kind
of
thing
and
then
we
can
kind
of
nail
this
down
and
move
it
forward.
I
A
Document
so
now,
with
a
semi
hat
on
sean,
and
I
haven't
conversed
on
it,
so
you're
witnessing
this
in
real
time.
Right
now,
I'd
say
that
whatever
disposition,
that's
given
whether
it
be
an
appendix
a
separate
document
or
just
ignored,
if
we
could
at
least
get
a
focus
on
the
ones
that
are
basically
agreed
upon
the
the
rest,
it's
not
that
it
doesn't
matter.
I
mean
it
is
good
to
document,
but
specifically
how
it
gets
documented.
I
don't
think
we
need
to
solve
right
now.
I
A
Yes,
I
personally
wouldn't
have
a
problem
with
seeing
it
as
a,
and
here
are
things
that
we
just
were
not
able
to
come
to
consensus
on.
A
B
Think
we
did
and
we
even
did
it
with
five
minutes
to
spare
fantastic
all
right,
so
I'm
gonna
pass
the
the
driving
over
to
you
dave
in
case
I
have
to
drop
because
okay,
I
would
lose
all
the
slides.
Did
you
download
the
slides.
A
E
A
B
A
C
A
A
C
Okay,
hello,
everybody.
We
are
felipe
and
dang
from
megalia.
I've
been
working
on
this
also
in
partnership
with
io.
C
I
have
three
main
points
here.
The
first
one
is
going
to
talk
about
some
proposed
changes
to
the
respect
are
currently
in
the
github
repo,
and
then
we
have
time.
We
can
also
talk
more
specifically
about
the
resource,
preloading
use
case
and
its
relationship
with
some
work
that
is
going
on
on
the
javascript
side
of
things.
C
C
C
And
finally,
we
think
it
would
be
also
a
good
idea
to
remove
content
negotiation,
because
it
would
be
more
efficient
to
do
the
content
negotiation
on
the
server,
so
the
server
decides
which
information
to
send.
So
it
sends
only
the
information
that
the
client
is
going
to
use,
rather
than
sending
all
the
variants
to
the
client
and
then
having
the
client.
Do
the
content
negotiation
on
on
its
own.
C
C
And
finally,
after
removing
these
fields,
one
proposal,
one
idea,
one
question
that
I
would
like
to
to
post
it
whether
it
would
make
sense
to
work
on
a
secondary
document
for
a
more
specific
use
case
for
the
use
case,
where
you
can
browse
into
a
bundle
where
the
bundle
has
this
additional
information
and
lets
the
browser.
Take
it
as
a
self-contained
website,
and
there
are
some
interesting
use
cases
that
maybe
not
everybody
is
interested
in
working
on.
C
So
I
guess
my
question
is
whether
it
will
make
sense
to
have,
on
the
one
hand,
the
simple
base
specification
that
focuses
on
the
consensus,
use
cases
and
then
maybe
an
extension
specification
for
some
generally
some
use
cases
that
are
not
as
general,
but
and
that
require
a
more
complex
bundle
format
and
now,
before
continuing.
I
think
we
can
have
a
discussion
about
these
points.
I
Yes,
so
these
all
of
all
of
these
seem
like
plausible
things
to
to
remove
or
to
move
out
into
separate
documents,
and
I
really
want
the
the
working
group's
opinion
on
on
whether
to
do
it
rather
than
kind
of
just
having
us
debate
among
the
people.
Editing
the
spec.
I
Removing
the
primary
url
section
is
interesting
because
in
the
follow-up
use
case
of
being
able
to
navigate
to
these
things,
sticking
it
in
a
known
location
allows
us
to
redirect
there
when,
when
something
is
broken
like
when
a
version
number
is,
is
unsupported
or
the
critical
section
lists
lists
something
the
client
doesn't
support,
and
so
by
by
taking
this
out,
we
still
serve
the
use
case
of
of
sub
resource
loading.
But
we
weaken
one
of
the
other
use
cases
a
bit.
I
We
should
still
be
able
to
support
it,
the
manifest
section
we
probably
don't
lose
anything
beyond
efficiency,
and
we
can
add
it
back
in
and
it's
a
separate
document
content
negotiation
is
the
really
interesting
one
it's
here
because
I
was
trying
to
represent
http
and
http
has
content
negotiation,
but
it
adds
a
bit
of
complexity
and
it's
not
clear
that
you
would
ever
use
this,
except
in
some
some
narrow
cases.
I
If
you
want
to
distribute
a
translated
version
of
wikipedia,
for
instance,
on
an
sd
card,
you
might
want
content
negotiation
in
the
format,
but
for
all
of
the
online
use
cases,
it's
probably
a
bad
idea
to
use
it.
So
again,
if
we
remove
it,
all
of
the
use.
Cases
should
still
work,
but
we
represent
http
less
well
and
I'm
curious
what
what
people
think
about
that
trade-off.
D
D
D
Okay,
so
I
I
would
avoid
the
word
negotiation
because
it
implies
a
conversation
with
some
other
entity.
It's
it's
sort
of
content
of
multi-content
formats
available
available
or
something
we
keep
saying
use
case
just
saying.
A
There
has
been
some
active
jabber
conversation
now,
there's
one
of
the
participants
welcome
to
the
queue
martin.
G
Going
through
these
one
by
one,
I
think
the
the
primary
url
thing
has
always
been
sort
of
overwrought.
I
I
can
sort
of
see
the
rationale
for
it.
You
have
a
versioning
system
and
you
have
a
an
elegant
fallback
in
the
case
that
the
version
changes,
but
it
turns
out
that
we
already
have
a
relatively
elegant
version
negotiations,
sort
of
mechanism.
G
It's
called
content
types
and
or
media
types,
and
you
find
that
if
you
don't
support
the
media
type,
then
you
don't
support
the
content
and
that,
I
think,
is
sufficient
in
this
case
and
building
a
redundant
mechanism
is
probably
not
what
we're
looking
for.
So
I
would
not
go
there.
The
manifest
section.
I've
no
strong
opinion
on.
I
I
think,
having
a
reasonable
thing
there
would
be
pointed
out
is
reasonable.
G
Now,
content
negotiation
is
clearly
complexity
and,
to
some
extent,
adding
extra
markdown
files
to
some
repository
is
not
really
in
scope
for
the
working
group.
It's
the
content
of
the
document
that
we
should
be
discussing
and
the
content
of
the
document
should
contain
the
content
that's
been
proposed
for
this.
I
haven't
reviewed
the
content,
but
I
I
think
in
general,
if
you
have
a
specification,
the
specification
should
explain
what
it
and
putting
that
in
a
separate
document
doesn't
make
a
lot
of
sense
to.
A
A
And
not
to
put
anyone
on
the
spot,
but
daniel
since
you've
been
having
active
involvement
in
the
jabra
conversation.
Would
you
like
to
add
some
for
the
microphone
record
here.
K
So
thanks
for
the
you
know,
positive
responses,
everybody.
This
is
what
felipe
and
I
have
been
working
on
for
for
some
months,
and
I
hope
that
these
these
changes
can
really
keep
us
focused
on
what
I
think
is
the
most
some
of
the
most
important
use
cases
which
are
accelerated
loading
of
sub-resources
on
the
web.
K
I
think
they're
there
there's
some
interesting
discussion
on
jabber
about
what
this
means
for
offline
and
peer-to-peer
use
cases,
and
I
think,
there's
been
a
lot
of
interest
expressed
about
those
but
there's
there's
a
lot
of
different
open
questions,
and
I
do
think
that
it
will.
It
will
take
a
bunch
of
focus,
work
that
makes
sense
to
publish
in
a
different
document
yeah.
I
don't
know
I'm
happy
to
answer
any
any
questions
about
the
motivation
for
these
also,
but
felipe
did
a
great
job
explaining.
D
Thank
you,
rick.
Please
talking
about
the
offline
and
peer-to-peer
use
cases,
so
the
dtn
working
group
is
a
transport
working
group,
specifically
looking
at
store
and
forward
offline
and
peer-to-peer
use
cases,
a
transport
layer
bring
bring
it
to
us
at
a
later
date
and
we
can
work
on
it
there
or
with
you
or
whatever,
keep
it
out
of
scope.
At
the
moment
there
are
other
people
who
can
help
do
this,
but
it's
part
two
not
part
one.
A
Okay
and
watson,
please.
L
I'd
like
to
point
out
that,
if
you're
going
to
talk
about
browsing
into
a
bundle,
you're
going
to
have
a
host
of
questions
about
the
purpose,
especially
wanted
to
be
a
long-term
format
for
things
like
documents,
there's
gonna
be
questions
about
like
what
kinds
of
images
you
can
use,
et,
cetera,
et
cetera,
et
cetera.
A
F
Already
speaking,
I'm
okay
with
this
being
step
two,
but
I
think
it
makes
me
even
more
anxious
that
jeffrey's
point
earlier
about
keeping
in
an
appendix
the
the
list
of
things
that
maybe
aren't
our
first
goals
but
are
still
motivations
for
the
work
is
important,
because
there
are
certain
things
that
you
could
do
once
you
you
head
down
the
the
path
without
this
as
a
motivator
that
will
close
it
off
for
the
future,
and
I
would
be
very
sad
about
closing
that
off
for
the
future.
F
As
long
as
we're
all
clear
that
it's
being
pulled
into
a
different
document,
it'll
use
the
extension
format
and
the
different
document
to
describe
it
and
we'll
deal
with
that
complexity.
And
I
totally
agree
with
the
point
that
was
made
by
watson
that
there
is
some
significant
complexity
to
deal
with
there.
F
A
Okay,
thank
you,
ted
and
oh
daniel's,
back.
K
K
If
there's
a
parsing
error
that
you
need
to
recover
from,
then
you
could
redirect
I'm
not
I'm
not
sure
about
that,
but
all
the
other
ones
like
content
negotiation,
you
could
have
like
a
different
kind
of
index
in
a
different
section.
Some
things
might
be
a
little
bit
ugly,
but
I
think
they
would
all
be
possible
because
of
the
extensible
section
architecture,
so
I
don't
think
we're
cutting
ourselves
off
of
any
of
any
future
paths
and
I'm
happy
to
go
into
details
about
how
that
would
work.
If
people
want
to
discuss
it
further.
A
I
also
mentioned
because
I
saw
something
interesting
go
by
and
chat
that
alexi
had
mentioned,
that
I
like
the
idea
of
some
mandatory
to
support
for
some
use
cases,
extensions
in
a
separate
document
to
exercise
the
extensibility.
I
don't
know
whether
that's
going
to
get
traction,
but
that
was
a
that
was
a
thought
that
was
out
there.
A
I
think
that
we've
actually
wrapped
up
discussion
on
this
point,
though
felipe.
If
you
want
to
move
forward
and
by
the
way,
welcome
back.
C
C
C
We
have
github
repository,
we
have
where
we
have
been
working
and
where
we
are
going
to
keep
working
in
the
in
the
coming
days,
and
then
the
chromium
team
has
an
experimental
implementation
of
very
similar
ideas.
We
also
elaborated
the
document,
at
least
in
the
small
differences
between
these
two
proposals.
C
So
they
can
be
used
in
the
website
in
the
most
efficient
manner,
and
this
works
well,
but
there's
a
couple
problems.
First,
that
is
not
as
efficient
as
it
could
be
because,
for
example,
retrieving
resources
from
a
bundler's
output
is
quite
costly
and
also
it
doesn't
fit
well
with
the
catching
strategies
that
browsers
use
and
then
the
strategies
and
that
bundlers
use
are
not
standardized
and
they
are
not
interoperable
between
the
different
vendors.
C
So
our
goal
with
this
work
is
to
find
a
solution
to
be
able
to
distribute
web
content
efficiently,
a
solution
that
is
standard
interoperable
that
keeps
the
benefits
of
bundlers
from
the
point
of
view
of
developers
in
the
different
strategies
that
they
can
use
and
the
performance
benefits,
but
at
the
same
time
we
also
keep
the
benefits
of
accessing
individual
resources
that
can
be
catch
individually.
That
can
be
fetched
with
more
flexibility.
C
C
C
And
for
developers,
this
wouldn't
make
big
changes
in
the
tools
that
they
use
and
other
studies
that
they
are
already
using
remain
possible
for
the
servers.
We
want
to
make
sure
that
there
are
no
additional
penalties.
If
this
format
is
no
support,
the
server
just
serves
the
resources
one
by
one
and
for
the
browsers.
We
want
to
make
sure
that
we
fit
in
the
studies
that
they
use
to
fetch
and
to
keep
resources
in
the
case.
C
From
the
point
of
view
of
the
user,
we
also
want
to
make
sure
that
we
do
not
enable
disguising
personalized
content.
Intuitively
bundler
bundles
should
be
used
for
resources
that
are
common
to
all
the
users
of
a
website,
with
individual
responses
being
used
for
specific
files
that
are
specific
for
the
current
user.
C
We
also
want
to
make
sure
that
this
is
compatible
with
content.
Blocking
that
are
trusted.
Intermediary
cannot
repackage
sites
that
we
do
not
enable
the
cheap
rotation
of
urls
in
the
bundle
and
that,
if
a
content
has
been
blocked
from
being
fetched
through
an
individual
request,
it's
also
blocked
from
being
feds
through
a
bundle
request.
C
You
have
a
javascript
api
that
lets
you
do
exactly
the
same
in
an
imperative
way
and
both
of
these
end
up
causing
an
http
request,
where
the
browser
adds
that
bundle
preload
header
listing
the
specific
resources
that
it
is
requesting
and
the
http
response
must
be
a
bundle
response
following
the
spec
that
we
have
been
talking
about.
Containing
the
http
responses
for
each
of
the
urls
that
has
that
have
been
requested.
C
But
because,
with
this
approach,
the
developers
can
have
more
granularity
with
how
they
update
a
single
resource.
Then
we
think
it
will
have
also
better
performance
in
terms
of
terms
of
cassette.
C
These
modules
can
then
be
imported
dynamically
or
statically
in
other
parts
of
the
code,
and
they
could
be
exported,
so
they
would
be
accessible
from
outside
from
other
source
files,
and
this
change
would
let
you
reorganize
the
javascript
code
in
a
in
a
native
standard
way
compared
with
resource
preloading.
Resourceful
loading
works
more
at
the
network
level
on
resources
of
any
type,
whereas
module
fragments
is
a
solution
specifically
for
for
javascript
and
limited
to
javascript
files.
C
But
together
these
two
approaches
we
think,
can
provide
a
high
performance
standard
solution
for
bundling
for
the
web.
C
So
you
could
use
javascript
module,
fragments
to
reduce
and
reonga
reorganize
and
optimize
your
javascript
source
files,
dividing
them
in
chunks
as
they
need
to
be
loaded,
distributing
them
any
way
that
fits
the
website
and
then
with
bundled
preloading.
You
could
distribute
these
resources
and
others
in
a
more
efficient
way.
C
B
A
Presented
you
were
getting
feedback
all
along
in
jabber,
but
all
of
a
sudden
people
become
mic
shy
so
which
is
totally
fine.
Of
course,
if
nobody
really
wants
to
bring
anything
back
to
the
mic
and
we'll
handle
everything
on
the
list,
that
is
totally
a
fine
option
and
you'll
get
a
little
bit
of
time
for
the
end
of
the
session
back.
A
And
in
the
side
chat,
I've
asked
our
ad
if
she
wanted
to
comment
at
all,
and
she
also
has
nothing
more
to
add
right
now.
So
this
is
your
chance
for
last
minute
comments
before
we
move
forward
and
retreat
to
online
on
the
list.
K
I
was
going
to
try
to
ask
martin
for
his
feedback,
but
I
guess
we
didn't
give
adequate
time
for
preparation.
Yeah.
A
It
was
not
adequately
warned
for
this.
Unfortunately,
so
I
would
be
looking
forward
to
the
list.
Conversation
watson,
please.
L
L
L
How
do
you
handle
that?
Is
it
possible
when
you
introduce
this,
you
start
having
problems
where
all
these
javascript
files
used
to
be
well
cached,
but
they
weren't
really
changing,
but
now
they're
in
a
bundle
and
you're
sending
the
same
bytes
back
and
forth
every
time,
just
because
something
else
in
the
bundle's
changing.
A
K
Those
are
two
really
good
questions
so
about
the
cache
lifetime.
The
idea
is
that
each
response
in
the
bundle
would
have
its
own
header
for
for
its
cache
control
and,
as
felipe
said,
you
know,
we,
we
kind
of
expect
bundlers
to
continue
to
use
the
technique
of
revving
of
changing
urls
to
to
get
the
kind
of
caching
behavior.
That's
that's
requested
about
when
one
resource
in
a
bundle,
changes
and
the
others,
don't
the
the
semantics
were
picturing
for
loading
bundles
on
the
web.
K
K
The
answer
in
our
current
proposal
is
no
the
there's
an
exhaustive
list
of
the
files
that
you're
asking
about,
and
that's
I
mean
the
sorry
resources.
Sorry,
the
resources
that
you're
that
you're,
referring
to
and
those
ones
in
the
in
the
client
would
specifically
be
kind
of
mapped
to
the
the
bundle
response
and
anything.
That's
not
specifically
listed,
wouldn't
be
especially
reserved.
But
this
is
kind
of
a
question
that
we've
gone
back
and
forth
on
in
different
versions
of
the
design,
including
different
versions
that
that
people
in
the
chrome
team
have
produced.
A
Thank
you.
We
are
once
again
back
to
an
empty
queue,
though
prompting
further
discussion
to
go
back
to
the
list,
and
so,
with
apologies
from
the
chairs
for
inadequately
preparing
for
this
discussion.
A
I
think
sean
is
jumping
on
to
give
oh
I'm
gonna
say
last.
A
B
Is
that
it
for
you
sean
dad
and
just
be
ready
for
the
mailing
list?
I'm
gonna
we're
gonna
I'll
ping
jeffrey
to
make
sure
we
get
a
new
version
of
the
use
case
document
and
expect
a
working
group.
Adoption
call
to
go
out
and
I'll
ping.
Everyone
who
spoke
during
the
discussion
to
provide
input
thanks.
A
Yeah
hi
everybody
just
hi
everybody.
I
just
wanted
to
raise
awareness
in
this
working
group
of
the
http
message.
Signatures
work,
that's
happening
in
http
just
because
that
I
know
has
some
overlap
with
some
of
the
interests
in
this
group.
My
apologies.
A
I
have
not
been
following,
what's
been
going
on
in
wpac
closely,
although
I
would
like
to
start
working
more
closely
with
this
community
as
we
bring
the
message
signatures
work
forward,
and
thank
you
great
thank
you
that
cross
fertilization
very
important
so
and
I
believe
we
are
all
done
here.
You
get
an
extra
five
minutes
into
break
and
please
enjoy
the
rest
of
your
ietf
week.