►
From YouTube: IETF108-WPACK-20200731-1300
Description
WPACK meeting session at IETF108
2020/07/31 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Hello,
all,
oh
there
popped
up.
I
believe
you
can
all
hear
me
tell
me
if
not
because
that
would
work
we're
going
to
get
started
on
the
web
packaging
session
here
at
virtual
ietf
108
as
usual
for
all
the
other
working
groups,
you've
likely
been
attending
all
week.
You
should
please
make
sure
your
video
is
off
and
sean
is
scrolling.
The
slides
away
on
me
also,
you
don't
have
to
worry
about
muting
your
microphone
unless
you're
speaking
because
of
the
whole
permission
system
and
meet
echo.
A
You
are
already
here
in
echo
and
jabber
and
as
usual,
the
notewell
which
you
should
be
very
familiar
with,
applies
to
this
working
group
and
oh
I'm,
david
lawrence
tale
and
sean
turner
is
going
to
be
driving
these
slides
for
us
today
we
have
a
relatively
simple
agenda,
only
two
really
two
main
items
that
we're
trying
to
cover
right
now,
but
I
need
to
see
hi
siobhan,
where,
where
else,
what
else
do
we
have
on
the
working
group
slides
here
sean
after
the
notewell
was
well
the
no
well
it's
the
end
of
the
week.
B
A
Okay,
I
think
actually
sean.
You
should
probably
re-lead
the
document
status
update.
I
I
apologize
because
I
realize
you
have
the
kids
nearby,
but.
B
A
Yeah,
I
think
that
is
probably
best
so
jeffrey
if
you
could
request
your
q
access
and
so
just
for
a
quick
little
bit
of
that
is
sean
is
juggling
family
at
home
right
now,
so
we're
just
going
to
move
the
document
status
updates
to
the
end.
So.
D
E
F
C
C
We
basically
have
a
problem
of
designing
a
url
scheme
go
to
the
next.
C
Slide
so
url
design
looks
like
a
bike
shed,
it's
not
actually
quite
as
complicated
as
an
atomic
power
plant,
but
it's
it's
also
not
quite
as
simple
as
it
looks
so
go
to
the
next
slide.
C
Yep,
it
said
something
went
wrong
anyway
for
the
for
this
discussion,
a
bundle
lives
at
a
url.
Once
you
fetch
that
url
you
get
a
map
from
claimed
urls
to
resources.
Next,.
C
C
So
we
we
need
to
figure
out
how
we
name
the
things
inside
of
a
bundle
from
from
outside
the
bundle
so
that
we
can
stick
them
into
say,
image,
tags
or
link
to
them.
There's
a
couple
draft
existing
drafts
that
talk
about
this.
C
C
Unfortunately,
we
have
when,
when
doing
this
on
the
web,
we
have
to
think
about
what
the
origin
of
any
of
these
resources
are.
This
especially
matters
when
you
use
something
as
inside
the
bundle
as
either
a
top
level
html
page
or
an
iframe,
and
so
these
these
things
need
to
have
storage,
and
I'm
not
going
to
go
into
the
details
of
why
in
this
presentation,
but
we
have
to
figure
out
where
their
storage
lives.
C
So,
if
you
have
this,
this
bundle
or
a
resource
inside
a
bundle
say
you
have
an
archive
made
on
april
1st
of
this
website.
What
storage
or
does
it
share
storage
with
any
other
resources?
Should
it
match
up
the
archive
storage?
Should
it
match
the
storage
for
the
same
page,
but
archived
on
a
different
day?
C
And
I
think
the
answer
to
all
of
this
is
no
it
should
it
should
have
distinct
storage
from
from
all
of
these
and
yeah,
as
martin
says
in
the
chat
when
on
the
web,
when
we
ask,
should
this
share
storage
with
we
we're
asking?
Is
this
same
origin
with
on
the
list?
There
was
general
agreement.
C
C
Yeah,
so
martin
suggested
that
maybe
we
can
nest
bundles
instead
of
having
the
the
origin
of
the
bundle.
Url
include
the
the
sub
resource
origin
there.
This
this
seems
like
it's
it's
possible,
but
a
little
bit
more
complicated
or
possibly
more
complicated
than
than
the
stuff
that
I'm
going
into
here.
So
I
haven't,
I
haven't,
pursued
it
further.
C
If
we
went
this
way,
we
would
have
to
define
a
way
to
navigate
kind
of
up
a
bundle
without
knowing
which
which
bundle
you're
inside,
but
otherwise
it's
probably
doable,
and
so
at
the
end
I'm
going
to
ask
kind
of
which,
what
semantics
we
actually
want,
whether
we
can
whether
we
can
firmly
decide
on
on
the
semantics
at
this
meeting
next
slide.
C
So
I'm
I'm
suggesting
that
to
set
the
origin,
it
doesn't
work
to
just
use
fragments
because
the
origin
algorithm
depends
on
the
scheme.
So
we
have
an
hps
scheme.
The
origin
doesn't
depend
on
the
fragment.
We
should
define
a
new
url
scheme
and
there's
five
five-ish
overall
syntaxes
that
that
look
plausible.
C
Which
makes
this
relatively
straightforward
to
read,
but
it
means
that
the
the
origin
depends
on
part
of
the
fragment,
which
is
a
little
weird.
A
second
option
is
to
define
a
new
scheme.
That
includes
includes
two
different
urls,
not
not
encoded,
very
much.
There's
this
dollar
sign
separator
that,
if
it
appeared
inside
of
one
of
them,
would
have
to
be
encoded,
but
everything
else
kind
of
stays,
as
is,
but
here
you
you
have
to
really
parse
this
to
figure
out
where
the
origin
stops
next
slide.
C
C
So
you
you
wind
up
with
kind
of
a
link
to
a
to
a
fragment,
url,
redirecting
or
or
somehow
switching
origins
to
to
this
hash
based
url
once
you're
once
you're
at
one
of
these
hash
based
urls
you,
you
completely
can't
read
the
url
like
it's
a
it's
a
hash,
and
so
it's
kind
of
hard
for
the
browser
to
tell
you
where
it
came
from,
but
but
it
it
could
still
probably
work.
C
C
So
the
the
proposal
that
that
I
actually
favor
is
this
3a,
where
you
encode
the
two
urls
to
distinguish
the
the
bits
that
contribute
to
the
origin
from
the
bits
that
are
just
part
of
the
path,
and
so
this
way
the
the
first
slash
actually
separates
the
the
origin
from
from
the
path
and
then
the
the
last
option
is
instead
of
having
a
custom
encoding
of
things
like
slashes,
you
just
use
percent
encoding
for
everything
that
that
looks
a
little
weird
and
it
it
makes
it
I
think,
even
harder
to
read,
but
it
it
doesn't
doesn't
need
an
extra
encoding.
C
Martin
asks
what
the
authority
in
3a
is
the
authority.
Well,
because
this
isn't
currently
a
colon
scheme,
there
is
no
authority,
it
depends
a
little
bit
what
you,
what
you
define
as
authority,
the
the
kind
of
entity
that
controls
the
content
is
archive.example,
so
the
the
host
name
of
the
of
the
bundle
url
and
a
little
bit
later,
I'm
gonna
talk
about
what
we
think
browsers
should
do
in
displaying
these
urls,
but
the
origin,
which
is
what
we
use
the
authority
for
in
https
urls.
C
So,
whatever
scheme
we
define
should
apply
to
more
than
just
the
bundle
format
that
this
group
is
defining,
it's
pretty
straightforward
to
to
apply
it
based
on
the
media
type
to
to
any
basically
any
container
format.
There's
also
this
bagit
format
from
another
rfc.
C
That
is
a
folder
structure
where
you
request
the
contents
separately
and,
if
basically
any
of
the,
if
we
defined
a
mime
type
for
any
of
the
the
top
level
resources
that
could
could
fit
that
into
this
scheme.
Also,
so,
whatever
whatever
draft
we
wind
up,
writing
should
should
define
a
registry
or
something
to
to
make
it
work
for
other
for
other
formats.
C
Next
slide
really
go
to.
So
what?
How
should
these
urls
behave
so
rendering
in
browsers
is
governed
by
the
which
basically
said
that
brothers
may
emphasize
the
the
host
or
the
registral
domain
and
in
the
case
of
a
bundle
url?
I
think
that
they
should
emphasize
the
the
registral
domain
or
host
of
the
bundle
portion
rather
than
trying
to
emphasize
the
origin
which
nobody
can
read.
C
C
Inside
of
a
single
bundle,
you
only
expose
the
claimed
urls.
This
allows
an
archive
to
just
archive
sites
and
not
worry
that
they're
going
to
get
confused
by
seeing
themselves
as
this
new
package
url
and
similarly
for
across
cross
resource
requests
like
post
message
and
the
referrer
header.
You
also
strip
the
the
bundle
url
kind
of
decode
the
package
as
long
as
it's
within
the
same,
the
same
bundle
outside
of
the
the
home
bundle.
C
You
do
expose
the
full
package
url
and
then,
when
you
fetch
one
of
these
it
it
decodes
the
url
and
and
actually
hits
the
network
with
a
fetch
of
the
of
the
bundle
url,
not
a
fetch
of
of
the
package.
Url.
C
Next
slide,
we
have
to
figure
out
how
to
or
what
origin
and
refer
headers
to
send
and
there's
an
algorithm
in
the
in
the
explainer
that
I
linked
at
the
very
top
of
the
of
the
presentation.
C
C
Strict
origin
or
origin
referrer
policies
that
drops
the
path
and
because
the
sub-resources
claimed
url
is,
is
kind
of
equivalent
information
to
the
path.
It
should
also
drop
that,
but
if
the
path
is
kept,
then
we
want
to
keep
the
the
sub
resources
origin
and
apply
the
subresources
referrer
policy
to
to
its
url,
and
then
everything
gets
merged
back
into
a
package
url.
C
So,
in
the
case
of
a
a
request
out
of
the
package,
it's
mostly
the
bundles
referrer
policy
that
that
matters.
C
So
if
you,
let's
see
yeah,
if
you're
navigating
to
the
same
within
the
same
origin,
then
you
can
keep
the
path
and
keep
the
the
information
about
which
resource
you're
requesting
at
least
some
of
it.
But
if
you're
going.
If
you
want
just
strict
origin,
then
you
drop
the
path,
and
this
shows
how
you
also
drop
the
the
information
about
which
resource
inside
the
bundle.
C
Let's
see,
martin
asks.
What
does
food
example
do
in
this
case,
because
food.example
is
serving
a
package,
they
at
least
had
the
opportunity
to
change
their
processing.
I
do
expect
this
would
confuse
some
existing
processing
code,
but
we
also
don't
want
we
would
we
would
rather
the
the
existing
processing
to
reject
requests
than
to
accidentally
accept
them,
because
a
package
is
likely
to
be
either
untrusted
or
or
less
trusted
code.
C
One
use
of
this
is
to
implement
sub
origins
with
packages,
which
is
a
a
separate
proposal
from
mike
west
that
that
most
of
you
probably
haven't
read,
but
we
we
basically
don't
want
people
to
accidentally
treat
packaged
resources
as
same
origin
with
themselves
and
so
providing
doing
package
sending
package
urls
by
default
should
help
with
that,
and
then
people
can
write
special
case
code
if
they,
if
they
want
to
accept
it.
A
link
to
a
page
martin
asks
about
a
link
to
a
page
on
a
separate
origin.
C
So
they'll
get
a
package
url,
which
is
a
format
they
don't
expect
at
all
they.
I
would
hope
that
they
would
just
treat
that
as
cross-origin,
but
that
is
a
hope
they
are
probably
vulnerable
to
to
existing
attacks
if
they,
if
they
just
crash
on
on
unexpected
url
formats,
because
there's
no
guarantee
that
that
a
browser
is
is
doing
the
request.
C
But
that
is
something
we
should
probably
check
anyway.
Next
slide.
C
So
here's
an
example
of
a
single
package
that
you've
downloaded
to
your
hard
drive.
If
you
navigate
inside
of
that
package,
we
want
to
keep
referrers
kind
of
by
default.
We
want
to
keep
the
internal
referrers
that
that
an
existing
site
would
have
seen,
and
so
here
we
because
the
file
is
is
an
opaque
origin
but
a
consistent,
opaque
origin.
C
C
So,
there's
a
couple
questions
to
discuss,
which
semantics
from
the
early
slides
once
we've
talked
about
that
what
syntax
to
use
and
then,
depending
on
the
syntax,
what
details?
What
details
of
that
syntax?
Should
we
pick
and
we'll
see
how
much
we
get
we
get
through
in
the
time
we
have.
G
Hey
am
I
live.
G
G
E
G
G
C
Yeah
so
slide
14
talks
about
how
we
expose
the
the
these
urls
to
programs
and
the
my
my
thought
was
that,
if
we
strip,
if
we
avoid
exposing
the
bundle
url
inside
of
the
bundle,
then
things
can't
depend
on
their
own
pads
and
the
refer
policy
handling
is
partly
to
prevent
exposing
file
urls
out
out
of
the
bundle
either,
because
the
default
referrer
policy,
strips
strips
paths
for
cross
origin
requests
the
all
of
the
file
pads
get
stripped.
If
you
make
a
request
out
of
the
bundle.
G
C
G
Okay,
well,
that
that
seems
reasonable.
I
I
C
B
A
We
actually
do
have
a
fair
bit
of
minutes
in
the
cody,
so
I'm
not
sure
who's
doing
it.
I
Well,
that
was
that
was
me
trying
to
keep
up,
but
it's
impossible
so
I'll.
A
I
That
is
fine,
so
I'm
having
a
fair
bit
of
trouble
with
the
notion
of
displaying
these
things
to
people,
no
matter
what
comes
about
the
problem
that
I
guess
ted
mentioned
with
the
theorises,
I'm
parsing
information
out
of
that.
What
am
I
expected
to
to
learn
when
I
look
at
one
of
these
things.
C
Right,
so
you
are
the
inference
based
on
that
first
domain
name
is
is
at
least
approximately
correct.
That
domain
is
the
one
that
has
the
power
to
change
to
decide.
What's
in
the
bundle
now
that
domain
may
have
decided
to
publish
a
bundle,
especially
if
it's,
for
instance,
an
archive
that
is
stuff
that
it
doesn't
fully
trust,
so
it
may
want
to.
C
I
All
right,
I'm
just
wondering
whether
there's
any
path
towards
having
an
authority
form
url
in
in
these
things.
I
suggested
something
in
my
draft
a
long
time
ago,
but
I
don't
know
if
it's
worth
worth
trying
to
trying
to
find
one
of
those.
I
don't
know
that
any
of
your
proposals
did
that,
but
you
you
would
have
to
create
an
authority,
that's
a
synthesis
of
the
the
entity
providing
the
bundle
and
something
I
don't
know
what
the
other
something
is.
I
suggested.
C
Right,
okay,
so
you
were
thinking
hashing
if
you
go
to
slide
10.
I
think
these
are.
These
are
the
closest
to
an
authority
form
and
in
fact
I
think
that
using
package
colon
slash
and
either
of
these
would
be
fine-
that
the
kind
of
the
authority
or
the
yeah
the
authority
is
that
that
origin
piece,
even
if
it's
not.
J
J
J
J
Is,
I
think,
most
critically,
the
fact
that
it's
a
bundle,
the
the
point
you
made
in
in
audio
but
isn't
quite
written
here,
the
what
that
means
is
the
bundle
author
has
the
right
to
change
which
resources
are
present
in
the
bundle,
but
may
not
have
the
ability
to
change
what
the
the
bundle
resources
are,
and
that's
very
hard
to
say
out
loud
in
ways
that
make
sense,
which
makes
it
me
suspect
that
getting
that
across
is
is
going
to
be
somewhat
difficult.
J
I
think
what
you're
you're
trying
to
get
at
here
is
that
to
the
programmatic
interfaces.
These
are
distinct
origins
when
they're
in
bundles.
J
The
bundle
creator
has
the
right
to
figure
out
what
resources
belong
in
the
in
the
bundle
and
when
treated
as
independent
resources.
You
want
to
know
who
the
bundle
creator
asserts.
They
came
from
right,
and
so
I
think
those
are
those
are
the
semantics
and
I
think
if
we
go
back
from
there
to
what
that
means
for
the
the
syntax,
I
I
think
what
that
means
is
you
actually
do
have
this
split
authority
thing
here
where
the
primacy
is
really
the
bundle?
J
The
the
the
person
who
created
the
bundle
is
the
authority
from
the
perspective
of
the
the
programmatic
interface,
but
not
necessarily
the
the
critical
piece
of
information
from
the
point
of
view
of
a
user
interface.
So
if
we
go
back
from
here
to
to
slide
13.
J
And
I've
misremembered
the
slide
numbers
the
one
with
3a
and
3b
on
it.
My
apologies.
J
My
apologies,
I
I
think
what
this
this
means
is
one
of
these
and
I,
although
I
have
a
slight
preference
here,
it's
not
really
important.
One
of
these
is
appropriate
from
a
programmatic
perspective,
because
they're
very
clearly
distinct
origins
to
to
the
origin,
that's
just
the
bundle
packager
or
just
the
the
claimed
resource
origin,
and
in
in
that
instance,
I
think
what
you're
saying
is
these:
these
are
very
distinct
programmatically.
J
What
you
would
end
up
doing
if
you
were
creating
a
ui,
for
this
is
not
use
the
common
ui,
but
you'd
actually
have
to
have
some
ui
element,
and
this
is
not
my
design,
expertise
that
says
the
grouping
in
the
first
part
of
this
up
to
the
percentage
percentage.
The
the
dollar
mark
here
created
a
package
for
you
which
contains
that
they
believe
came
from
over
here
or
that
they
assert
came
from
over
here
and
you
you
definitely
would
not
want
to
reuse
something
that
ever
said.
J
The
the
the
part.
That's
you
know,
camera
example
is
is
is
presented
as
if
it
was
the
the
creator
of
the
bundle,
and
you
definitely
never
want
to
say
that
archive.example
is
the
creator
of
the
resource.
So
I
think
you
actually
are
are
requiring
some
new
ui
elements
here
in
order
to
get
across
the
the
semantics
you
want
and-
and
I
think
that
what
that
ends
up
meaning
is
either
one
of
these
url
schemes
is
probably
fine
and
then
on
the
ui
side
to
convey
those
semantics.
J
None
of
our
current
presentation
mechanisms
are
going
to
get
that
subtlety
across
and
that
we
we
are
generating
work
for
our
colleagues
who
have
expertise
in
that
not
not
trying
to
build
it
here.
C
Yeah,
I
I
talked
to
emily
stark
about
that
question
and,
and
her
team
is,
is
opposed
to
putting
camera.example
in
browser
ui
for
fear
that
it
will
confuse
users.
J
E
Oh,
so
I'm
basically,
oh
and
my
webcam
failed
at
some
point,
so
I'll
go
ahead
and
turn
that
off
so
yeah
I
I
was
basically
gonna.
Come
back
to
this
same
slide.
Number
ten,
and
I
think
I
understand
what
you're
trying
to
do
with
these
two
different
kinds
of
ugliness
you're,
basically
trying
to
take
something
that
is
algorithmically
trivially
parsable
into
a
string
that
you
want
to
be
able
to
do
a
string
match
on
in
order
to
figure
out
whether
it's
same
origin.
E
You
also
want
something
that
has
the
proper
markers
that
would
keep
so
that
the
proper
markers,
so
that
whatever
the
solution
to
this
ui
problem
is
which
I
think
is
out
of
scope
for
this
working
group
that
needs
work
on
it.
I
strongly
agree
with
ted
that
we
want
this
to
look
a
lot
different
from
what
we
have,
because
otherwise
we're
going
to
confuse
users
one
way
or
the
other
on
the
where
this
came
from
question.
E
You
need
something
that
that
turns
into
that
like
easily
turns
into
that
what
you
present
in
the
ui
you
on
the
third
thing.
You
want
something
that
looks
enough,
not
like
a
url
that
people
who
try
to
do
kind
of
the
stupid,
don't
parse
urls
with
regex
won't
accidentally
parse
one
of
these
as
you,
it
seems
like
you're
trying
to
do
that
you're
trying
to
to
break
existing
bad
url
parsers
so
that
they
will
choke
on
this.
Is
that
a
is
that
a
design
goal
of
this,
or
is
that
just
a
happy
accident?
E
C
That's
that's
not
quite
why
I
avoided
slashes.
So
if
you
go
to
slide
eight,
you
see
the
the
form
that
just
embeds
two
urls
and
I
was
more
worried
that
this
would
that
be
difficult
to
write
or
a
little
bit
more
difficult
to
write
a
correct
parser
for
this
yeah.
E
Right
1a
1a
is
a
pile
of
cves
like
as
soon
as
I
saw
that
one
I
was
like
nope.
You
can't
do
that
because
I
mean
there's
all
sorts
of
stuff.
You
can
do
in
that
split
area
that
will
break
your
parser.
So
that's
like
I.
I
think
that
that
that
sort
of
the
things
on
slide
10
seem
to
me
just
sort
of
they.
They
tickle
my
spidey
sense
of
you're,
going
to
write
a
bad
parser
for
this
less
than
the
things
on
on
slide.
E
Eight
do
I,
I
think
I
I'd
like
to
reiterate
something
that
ted
I
think
brought
up
in
the
in
the
chat,
the
fewer
novelties
you
introduce
here,
the
fewer
implementation
bugs
that
are
going
to
end
up
being
security
vulnerabilities
later
on,
and
that
would
cause
me
to
lean
a
little
bit
more
towards
3b
than
3a
just
because
it
doesn't
have
a
a
shiny,
new
symbol
in
it.
E
That's
that
is
my
contribution
to
the
bike
shed
painting.
Thank
you.
G
G
So
if,
if
there's
a
bundle,
a
dot
wbn,
does
that
wbn
have
a
collective
signature
that
is
traceable
to
the
source
domain,
or
is
it
only
an
an
unvalidatable
collection
of
signed
objects
in
which.
G
Okay,
I
mean
at
some
level
there
has
to
be
some.
We
can
pretend
that
it's
not
cryptographic
for
the
moment,
but
at
some
level
there
has
to
be
some
way
of
attributing
resources
to
the
to
the
source
domain.
To
I
don't
have
names
for
these
two
two.
G
Sure
so
that
claim
has
to
be
verifiable
in
some
way
or
or
this
is
all
you
know,
nonsense
and
of
course
we
intend
to
have
some
way
to
verify.
C
C
G
C
Right
archive,
when
you
fetch
this
package
url,
you
fetch
hbs
colon
archive.example,
something
and.
C
Gives
you
confidence
that
archive.example
actually
said
what
what
it
said
right,
but
then
it's
the
one
claiming
that
that
it
has
content
for
camera.example
and
we
don't
trust
that.
G
Okay,
well,
I
find
this
very
confusing.
I
don't
I'm
surprised
that
there's
any
I'm
surprised
that
there's
even
a
concept
of
of
of
allowing
a
claim
to
be
camera.example
without
a
validation
mechanism
that
that
isn't
a.
G
I
guess
that
that
goes
to
your
archival
use
case
as
opposed
to
your
web
oriented
use
case.
But
it's
not
clear
to
me
that
browsers
need
to
be
aware
of
that
at
all
as
a
browser,
I
would
just
say
this
is
archival
example.
A
Of
that
for
the
list,
please,
okay,
because
we
are
starting
to
run
a
little
low
on
time
and
we
want
to
make
sure
that
we
cover
the
next
presentation,
martin's
still
going
to
jump
in,
I
with
his
usual
succinctness,
but
this
is
a
good
discussion
that
should
be
on
the
list.
Is
the
main
point,
so
thank
you.
I
And
medico
takes
a
little
while
to
settle
so
there's
a
larger
architectural
question
that
needs
to
be
answered
before
we
can
really
get
into
all
of
these
sorts
of
things.
So
one
of
the
things
that
I
imagine
would
happen
with
one
of
these
bundles
is
that
they
would
be
signed
or
something
by
camera,
for
example,
so
that
you
could
attribute
them
to
cameras
by
example
properly
in
some
way,
maybe
and
there's
a
lot
of
questions
about
how
we
do
that
eventually.
I
But
that
means
you
have
you
you
are
asking
questions
about.
Well.
Are
we
signing
parts
of
the
bundle?
Is
the
bundle
composed
from
content
from
different
origins,
and
I
can't
answer
any
of
those
questions
right
now,
because
I
don't
really
know
the
asset
or
those
other
things,
and
this
is
where
this
gets
really
tricky
for
me,
because
I'm
seeing
a
lot
of
complexity
here
that
I'm
not
sure
that
we
need.
I
So
I
don't
know
whether
we
need
to
put
camera
by
example
in
the
uri
in
any
meaningful
way,
because
maybe
it's
just
a
property
of
the
of
the
bundle
that
comes
out
when
you
pass
the
bundle.
That's
another
way
of
approaching
this:
I
don't
know
what
the
constraints
are
on
the
problem
and
given
an
unconstrained
problem,
we
get
unconstrained
solutions
and
that's
what
I'm
seeing
in
front
of
me
right
now,
which
is
not
very
reassuring.
I'm.
I
A
Yeah
yeah,
no,
I'm
just
not
sure
other
than
bringing
that
also
that
further
discussions
of
the
list,
the
point
the
point
is
well
noted.
I
am
a
little
unclear
at
the
moment
whether
sean
is
prepared
to
drive
your
next
set
of
slides.
C
Yeah,
so
on
the
on
the
last
topic,
I
guess
we
will
discuss
more
on
the
list.
So
great
another
thing
that
has
come
up
is
the
idea
that
it
would
be
nice
to
be
able
to
generate
bundles
in
a
streamed
way,
so
go
to
the
next
slide.
C
So
right
now
we
have
a
bundles
format.
Is
that
you
have
an
index
which
lists
all
of
the
resources
and
then
you
have
all
of
the
resources.
That
means
you
get
good
random
access
properties.
C
You
read
the
index
once
and
then
you
can
jump
straight
to
kind
of
whatever,
whatever
resource
you
want,
but
you
and
you
and
you
can
streamload
these
once
you
get
past
the
index,
you
know
where
all
of
your
resources
are
going
to
be
and
you
can
load
them
as
you
get
to
them,
but
you
cannot
generate
these
in
a
streamed
way.
So
unless
you
have,
unless
you
know
all
of
the
sizes
of
the
resources
you're
you're
going
to
send,
you
can't
generate
the
index
so
go
to
the
next
slide.
C
Let's
see
the
the
random
access
and
stream
loading
are
not
quite
as
as
fast
as
they
could
be,
mostly
just
to
keep
the
format
simple.
So
we
could,
we
could
add,
b
trees
to
make
random
access
faster
and
for
streamloading
we
could.
We
could
interleave
names
with
bodies
which
would
then
break
random
access
next
slide.
C
And
yeah,
as
I
said
there,
there
is
no
support
for
stream
generation
and
so
again,
interleaving
names
and
bodies
would
allow
that
and
the
question
is:
should
we
so
the
next
slide.
C
There's
a
couple
use
cases
for
stream
generation
this.
This
got
raised
by
one
of
the
folks
on
our
ads
team,
who
wants
to
do
ad
auctions
and
serve
all
of
the
results
in
one
bundle,
but
allow
some
of
the
auctions
to
be
for
the
top
of
the
page
and
so
have
to
complete
very
quickly
and
other
auctions,
be
for
the
bottom
of
the
page
and
be
able
to
run
for
a
little
longer
and
without
stream
generation.
You
can't
do
that.
C
There
are
other
pre-loading
cases
where
you
might
have
front
ends
with
multiple
back-ends
and
there
there's
probably
other
other
use
cases
where
you
you
want
to
start
sending
a
bundle,
but
you
don't
have
all
of
the
all
of
the
metadata.
Yet
this
would
also
optimize
stream
loading
time.
If
you
have
a
whole
lot
of
resources,
you
might
not
want
to
wait
for
the
whole
index
before
you
start
loading.
The
first
resource
next
slide.
C
The
the
overall
sketch
of
what
we
would
do
to
to
add
stream
generation
is,
the
format
would
have
two
variants.
We
would
drop
support
for
random
access
from
the
stream
generation
version.
We
would
do
something
similar
to
push
promise
where
you
would
say
here
we
would
have
some
frames.
Some
of
the
frames
would
be
promises
for
for
future
resources
and
then
later
you
would
fulfill
those
promises
with
actual
resources.
C
Any
any
signatures
or
hashes
would
come
with
the
names,
so
it
would
also
not
have
to
be
upfront
so
next
slide,
and
the
question
is:
is
this
worth
doing,
and
basically
I'm
asking
this
group
like
do
you?
Do
you
think
we
should
and
that's
the
last
slide,
and
I
did
not
follow
the
chat
during
this
talk.
So
please
repeat
them
in
anything
in
comments.
G
Hi,
it's
if
I
understand
this
correctly,
if
you
have
streaming
generation,
the
client
can't
validate
the
bundle
as
a
collective
object,
going
back
to
my
last
hobbyhorse
until
it
has
received
the
entire
bundle.
C
That
is
correct,
you
could,
you
could
validate
chunks
kind
of
as
you
get
the
chunk.
G
Right
so
that
seems
to
me
like
a
worrying
security
property
where,
in
these
different
modes,
the
the
validation
properties
of
the
bundle
change,
or
at
least
temporarily,
during
the
loading
process.
So
potentially
an
advertary
could
take
a
bunch
of
components
of
bundles
that
I've
made
and
glue
them
together
into
a
streaming
bundle.
That
appears
valid,
at
least
until
the
end
of
the
streaming
process
or.
C
The
components
would
be
responsible
for
protecting
against
that.
If
they
signed
a
chunk
of
components,
then
it
would
not
be
possible
to
kind
of
to
separate
them
into
into
ones
that
are
that
look
like
they
were
separately
signed.
But
if
you
do
sign
them
individually,
then
any
of
the
bundle
proposals
would
allow
the
attacker
to
re
to
combine
ones
that
weren't
signed
together.
G
C
F
Hey
so
I
wanted
to
say
that,
regardless
of
signing,
there
is
value
in
bundles
like
outside
of
the
signing
use
case.
I
have
a
plan
to
make
use
of
web
bundles
as
a
way
to
send
multiple
resources
as
a
way
to
optimize
that
sending,
which
is
at
least
in
javascript
world,
currently
happens
as
concatenated
javascript
and
can
be
improved
in
many
ways:
performance,
wise
and
for
that
use
case,
I
have
a
sketch
which
can
live
with
the
current
restriction
of
bundles.
F
That
cannot
be
generated
on
the
fly,
but
only
can
be
substituted
on
the
fly,
but
at
the
same
time,
having
a
way
to
generate
bundles
on
the
fly
can
enable
adjacent
use
cases
where
some
of
the
content
is
dynamic
and
a
single
bundle
can
contain
both
content.
That
is
dynamic
and
static.
I
don't
have
a
strong
opinion
regarding
the
the
effect
of
this
on
this
signing
guarantees
of
the
bundles,
and
maybe
we
want
to
add
some
limitations
on
signed
bundles,
but
for
unsigned
bundles.
This
could
be
a
very
helpful.
I
So
I'm
sort
of
wondering
how
this
has
evolved
into
a
serving
live
content
scenario
as
a
result
of
the
discussions
we've
had.
I
mean
this
to
me
if
you're
talking
about
putting
in
in
features
to
support
serving
live
serving
of
content,
that's
dynamic,
you're,
now
talking
about
building
a
scheme
that
is
competitive
with
http
or
similar,
and
I
don't
quite
understand
why
that
would
be
necessary.
I
Okay,
so
when
we
discussed
this,
that
was
not
really
something
that
I
imagined
was
in
scope.
So
that's
a
little
surprising
to
me.
I
understand
the
general
complaint,
but
this
is
something
that's
been
raised,
a
number
of
times
in
the
past
and
the
usual
response
is
turns
out
that
too
many
requests
isn't
that
terrible
a
thing
and
you
can
mostly
get
by
with
without
having
too
many
problems
like
that,
but.
H
Oh,
I
was
gonna
say
something
wrong
to
similar
to
martin,
like
we're
not
here,
to
design
a
general
purpose
replacement
http,
which
this
is
starting
to
smell,
like
I'm
worked
through
the
entire
requirement
set,
but
I'd
be
quite
surprised.
There
wasn't
some
way
to
solve
this
problem
that
did
not
require
you
know
did
not
require
stuffing
the
ad
in
the
bundle.
H
In
particular,
it's
not
gonna
be
that
it
needs
to
be
signed
because
the
ads
not
just
served
on
the
origin
page,
it's
just
somewhere
else,
also
like
like.
Let's
not
pretend
the
entire
bundle
is
delivered
in
one
in
one
network
or
on
trip.
It's
not
so
there
are
other
opportunities
in
advanced
tuition
that
do
not
involve
like
that,
involve
multiple
request
responses
during
the
like
during
the
multiple
round
trips,
when
this
thing
is
delivered.
H
C
So
I
think
I've
heard
more
arguments
against
doing
this
than
than
for
doing
it
to
the
to
the
extent
that
people
want
to
do
it.
Let's
keep
keep
bringing
in
new
new
arguments
for
doing
it.
I'm
I'm
personally
fairly
neutral,
I'm
happy
to
do
it
if,
if
the
consensus
is
to
do
it
and
not
do
it
otherwise,.
D
We'll
obviously
take
it
to
the
list
and
I'd
like
to
thank
everyone
for
participating
and
we'll
see
you
all
next
time.