►
From YouTube: [OCI-WG] Reference Types - 2022-06-07
A
C
D
No,
this
is
silvan's
proposal,
but
I
will
happily
help
him
talk
to
talk
you
through.
Look
at
him
already
passing
the
blame
just
like
that.
No
it's
just
I'm
a
manager.
I
have.
I
have
so
many
other
things
to
do.
I
have
to
rely
on
good
engineers
like
sivan,
to
actually
help
me
I'm
good
at
talking.
I'm
I'm
not
good
at
finding
time
to
write
something
down.
E
Okay,
how
do
you
want
to
proceed?
Should
I
share
my
screen
and
my
document.
E
Okay,
so
the
idea
of
this
proposal
f
is
to
take
things
that
were
already
proposed
from
proposed
cnd
and
yeah
use
the
oci
index
and
the
nasty
lucian
dx
feature
followed
by
the
image.
E
Spec
use
everything,
and
so
we
can
propose
something
for
reference
type
without
any
api
modification.
So
that
was
the
main
goal
of
this
proposal.
E
That's
for
when
you,
when
you
add
artifacts,
attack
your
software
a
bit
of
material
to
venusia
index.
The
idea
is
to
the
digest
points
to
the
potential
manifest
that
is
referenced,
so
we
really
should
have
a
descriptor
pointing
to
that
that
manifests
inside
this
index,
and
these
are
this
reference.
E
Otherwise
we
would
have
a
kind
of
weak
reference
and
we
won't.
It
doesn't
prevent
the
registry
from
collecting
this
manifest.
But
please
stop
me
if
I'm
going
into
details:
okay,
okay,
so
that's
the
first
ad,
so
there's
already
a
predefined
annotation.
So
we
just
opened
those
free
annotations
to
this
list
and
the
idea
was
to
also
add
a
new
section
to
the
to
be
image
spec,
which
is
well
known
at
the
notations.
E
So
that
would
be
so
at
first,
I
did
some
cosine
a
cosine
example.
This.
The
idea
of
this
proposal
wasn't
to
propose
a
list
of
those
annotations,
but
just
the
section
so
I'll
remove
them
and
add
just
a
placeholder.
There.
D
I
think
it
is
good.
I
think
it
is
good
to
call
up
that
things
like
signatures,
or
you
know
smaller
objects
should
you
know,
can
go
at
the
top
level.
That's
that's
kind
of
where
we
came
like
signing
is
a
good
example
of
this,
because
that's
something
we
think
is
a
good,
a
good
candidate
for
this.
D
E
Is
to
add
a
plane
data
into
this
annotation
value,
like
small
data,
of
course,
for
this,
so
here,
for
example,
we
have
an
oc
index
pointing
to
as
a
manufacturer,
pointing
to
an
image-
and
we
add
annotations
that
okay,
but
it's
ice
cream
like
it
could
be
a
signature.
E
So
yeah,
that's
the
two
main
points
here
on
this
proposal
and
then
I
defined
two
scenery.
The
first
one
is
okay.
We
already
have
an
image
pushed
and
that
is
widely
used.
So
we
don't
want
to
change
the
tag.
We
don't
want
to
to
change
the
digest
by
this
tag
because
it's
already
consumed
so
the
idea
that
we
create
a
new
tag
and
we
push
another
ocr
index
and
there
we
use
the
oci
index
a
nested
index.
E
E
So
here
we
reference
the
former
aussie
index,
so
that's
the
nested
one,
and
then
we
recopy
the
this
ocadex
into
the
new
one
just
for
fallback
for
runtimes,
because
we
don't
we're
not
sure
that
all
runtimes
will
be
able
to
under
that.
I
mean
next
to
those
here
next,
so
they
will
fall
back
on
the
first
platform
they
will
match.
So
that
should
work.
E
And
then
we
open
also
annotations
here
for
like
this
one
is
a
cosign
and
then
we
add
a
new
artifacts
like
just
a
software
of
material
for
the
arm
64
and
for
the
md64
version.
Oh
yes,
jason.
C
So
this,
when
I
add
my
signature
to
this
index,
I
am
expected
to
retag
that
index
containing
the
original
image
layer
or
sorry,
the
original
image
references
and
my
new
s
bomb
signatures,
whatever
I'm
expected
to
tag
that
as
alpine
or
I
tag
that
as
my
original
image
thing
or
do
I
only
tag
this
as
with
the
digest
tag
that
you
showed.
C
C
I'm
probably
not,
then
I'm
supposed
to
tag
it
with
the
the
digest
tag
yeah.
I
wonder
so
one
of
the
the
digest
tag,
hack,
I'll
call
it
a
hack
because
I
was
involved
in
coming
up
with
it,
the
the
terrible
hack
that
is
the
digest
tag.
One
of
the
reasons
we
wanted
to
do
something
in
this
working
group
was
to
get
rid
of
those
tags
right
because
they
clogged
the
ui.
They
clogged
the
tag
list
endpoint
and
we're
still
not
getting
rid
of
it
right.
E
C
I'm
probably
going
to
list
through
a
bunch
of
tags
that
have
a
bunch
of
digest
crap
sitting
there
is
that
just
fine
like
like
it
may
be,
as
as
a
throughout
the
course
of
this
working
group,
we
have
decided
that
maybe
the
digest
tech
is
the
best
we
can
come
up
with
and
if
that's
the,
if
that's
the
end
result
of
this,
I'm
fine
with
that
I'd.
Just
like.
E
C
C
From
there
go
through
okay,
I
have
more
questions
but
I'll
lower
my
hand,
so
that
we
can
get
to
the
rest
of
you.
Okay,.
F
And
then,
just
as
a
comment
about
the
same
thing
like
this
depends
on
how
like
how
you're,
using
this
thing
right.
What's
your
use
case
is
like,
for
example
like
if
we
build
an
an
image,
for
example
like
alpine
latest,
and
it's
it's
already
signed,
and
and
we
don't
care
about
the
old
like
unsigned
image,
then
the
latest
stack
will
point
to
the
first
like
the
index
that
is
already
signed,
and
there's
no
need
for
this
tag
at
all
like
or
like.
This
is
like
an
optional
like
this
type.
F
Use
case
like
people
in
here
some
people
have
the
use
case
that
they
want.
They
want
to
know
what
signatures
point
to
the
unsigned
image,
and
if
they
have
this
use
case,
then
they
will
use
this
tag
for
that.
For
that
use
case,
but
it's
like.
If
they
don't
have
this
use
case,
then
they
will
just
use
the
image
directly
and.
C
Yeah,
so
I
guess
there's
there's
we're
splitting
the
use
case
into
like
the
image
originator.
I
I
build
alpine,
I
am
responsible
for
you
know,
producing
alpine
and
produce
and
sending
it
out
to
the
world,
and
I
can
attach
my
signatures
to
that
and
call
that
thing:
the
image,
references
and
signatures
and
s-bombs
as
alpine
latest
when
brandon
ingests
that
image
he
may
also
call
he
may
add,
a
signature
to
that
index
and
call
it
alpine
latest
within
his
repo
like
within
you
know,
I
have
ingested
it
into
my
org
and
it
is.
C
We
should
still
call
it
alpine
latest.
It
comes
with
a
signature
to
it,
show
you
that
that's
good,
but
that
digest
will
not
match
the
alpine
latest
from
docker
hub
or
from
upstream
wherever.
That
is
the
only
way
to
tell
if
they're
the
same
is
to
compare
the
manifests
and
see
if
they
contain
all
the
same
things
plus
whatever
I
added
right.
This
isn't
a
this,
isn't
a
question
or
a
problem.
F
F
If
you
want
to
want
to
have
a
way
to
like
find
the
site
manifest
from
the
unsigned
one,
for
example
like
like
find
the
one
that
was
the
original
one
and
find
the
one
that
was
now
has
two
signatures
as
well.
Then
you
would
use
that's
the
the
by
the
dac
by
the
by
the
that,
like
points
from
the
unsigned
manifest
to
the
to
the
signed
one.
B
B
I'm
gonna
throw
a
curveball
at
you,
though,
and
it's
one
that
I'm
just
kind
of
comfortable
with
looking
at
right
now
and
just
thinking
about
it
for
a
third
time,
which
is
take
like
the
rm64
image
that
we're
looking
at
and
we're
adding
a
flavor
ice
cream
to
it.
B
B
B
D
F
A
new
image,
and
then
you
call
it
like
this-
is
my
r64
image
or
whatever,
like,
however,
you'd
like
to
find
this
image
like
what
you're
almost
describing
is
like
like,
how
do
I
do
like
a
patch
signature,
or
something
like
this?
That's
like
that,
like.
B
F
Yeah,
if
you
have
images
that
have
different
versions,
then
yeah,
and
if
they're
like
separate
image
indexes
behind
those
different
version
text,
then
yeah.
You
need
to
sign
them
both.
F
F
I'm
saying
that
like,
if
the
is
that
those
are
two
tags
with
different
versions
and
it's
the
point
two
different
image
indexes
then
yeah,
like
both
of
those
image
indexes,
have
a
different
signature
like
the
the
like,
like
the
difference
in
here,
isn't
like
what's
like
what's
inside
it
or
is
it
like
an
arm
64
thing
or
what
whatever
is
inside
it?
It's
it's
that
if
the
tags
point
to
different
objects,
then
the
transition
objects
also
have
different
signatures.
If
the
tags
point
to
the
same
object,
then
then
they
of
course
share
the
signature.
B
C
B
F
Like
a
little
bit
similar
to
that
only
like
a
distrol
estebian
example
right,
like
the
old,
like
the
like
the
the
cosine
way
of
doing
it,
you're
always
like
adding
signatures
to
the
same
digest,
and
they
all
just
like
live
outside,
like
an
actual
definition
of
what
the
specific
like
specific
version
of
debian
was
like.
You
can't
really
see
like
what
is
the
signature
that
was
associated
with
the
stevian
image.
F
You
can
only
see
that,
like
this
different
image
was
built
like
30
times
and
there's
30
signatures
now,
and
that's
that's
how
that's
how
it's
like
kind
of,
like
all
the
signatures,
carry
over
to
all
the
other
images.
So
there's
like
one
way
to
look
at
it
is
yeah
like
this.
This
patch
signature
is
kind
of
like
neat,
because
it
automatically
picks
up
all
the
signatures
from
all
the
images
while
like
in
practice.
It's
also
like
it.
F
It
creates
a
lot
of
noise
as
well,
because
you're
you're,
seeing
lots
of
like
unrelated
signatures,
while
like
in
this
model
like
you're
you're,
specifically
the
signing
the
specific
tags
or
specific,
like
actual
like
image
instances.
It
isn't
that
like.
If
you
sign
one
of
those
images
and
it
references
one
of
the
like
the
inside
image
index,
there's
there's
a
inside
two
image
index.
There's
the
same
digest.
It
doesn't
mean
that
now
this
digest
has
like
two
signatures.
A
I
did
I
had
asked
this
in
the
in
the
pull
request,
but
since
we're
talking
about
nested
indices,
I
actually
have
not
seen
any
client
that
would
that
asks
for
an
index
like
it.
It's
almost
like
you
have
to.
If,
if
a
client
wants
to
find
the
right
index,
they
have
to
list
all
the
the
manifests
at
the
top
level
index,
and
then
they
have
to
find
the
one
that
matches.
B
A
A
C
B
A
B
F
The
spec
says
that
from
field
is
optional,
so
it
means
that
well,
like
sorry,
optional
and
it
defines
the
minimum
requirements.
F
So
it
means
that
when
it
doesn't
have
a
platform,
then
it's
like
automatically
matched
basically
that
that's
how
like
the
container
supports,
nested
indexes
as
well
like
the
nested
index
itself,
doesn't
have
a
platform
that
that
causes
it
to
like
go
deeper.
B
F
No,
but
we
should
make
it
sure
that
it
doesn't.
D
We
have
two
mechanisms
there,
we
have
the
media
type
and
the
and
the
platform
field.
F
The
the
media,
it
also
says
about
yeah,
like
it
says
that
media
that
needs
to
be
ignored
if
he
doesn't
understand
it
and
in
your
example,
actually
you
had
the
platform
unknown
there
right.
B
C
A
C
If,
if
an
index
has
multiple
nested
indexes
in
it,
should
I'm
going
to
rephrase
nisha's
question?
If,
if
an
index
has
multiple
nested
indexes
in
it,
should
it
search
breadth,
first
or
depth
first,
will
it
do
one
or
the
other?
Can
we
it's
not
specified
whatever?
It
is,
I'm
sure
it's
not
specified
so
like
what
what
will
a
runtime
do
today
and
what
should
a
runtime
do?
C
Do
you
want
me
to
explain
that
sure
I
mean
like
like.
F
Again,
yeah,
like
I,
I
think
it's
very
like
loosely
defined
and
mostly
defined
on,
like
the
basis
of
like
what
logically
works
like
but
like,
I
could
describe
how
it
works
in
container
d,
and
we
have
copied
the
same
thing
in
into
the
like.
The
new
docker
as
well
so
like
in
the
like.
The
latest,
like
the
beta
docker,
has
exactly
the
same
algorithm.
So
the
algorithm
is
that
you
pull
a
manifest
list.
You
have
a
list
of
descriptors
there.
F
Now
you
now
you'll
find
out
every
one
of
those
that
matches
your
your
platform,
the
the
description.
So
it
means
that
everything
that
matches
the
platform
and
also
like
all
the
empty
platforms
right
and
for,
for
example,
like
in
case
of
arm,
you
can
have
like
multiple
matches
like,
for
example,
you're,
pulling
pulling
an
arm
image,
and
you
have
like
a
descriptor
for
arm
v6
and
r
b7
and
both
of
them
match,
because,
because
like
if
you're
a
modern
arm,
you
can
run
either
of
them.
So
all
of
them
match.
F
And
now
those
descriptors
are
sorted.
So
that's
the
fuzzy
part,
that's
the
thing
that
puts
the
arm
b7
as
a
higher
priority
than
rb6
and
the
and
the
things
that
don't
have
a
platform.
I
thought
those
have
the
lowest
priority,
so
those
are
in
the
end
there
and
now
what
the
buller
wants
to
do
is
it
starts
to
cycle
through
those
descriptors
and
c
is
like
like.
F
I
want
like
all
the
all
the
platforms
or
like
all
the
images
that
have
a
matching
platform
or
anything
like
that,
but
like
in
the
case
of
how
do
we
went
through
the
first,
then
we
need
to
find
one
specific
object
that
that's
that's
where
the
algorithm
kicks
in.
C
Yeah,
I
think
this
algorithm
seems
complex
and
brittle
and
ill-defined,
and
I
think,
if
nothing
else
comes
out
of
this
group,
we
should
probably
define
that
algorithm
in
a
in
a
you
know,
specified
rigorous
way
with
unit
tests
with
test
cases
that
you
know
with
really
malformed
crazy,
weird
nested
manifests,
and
then
you
know
prove
that.
That's
what
we
do.
The
complex
part.
C
F
C
Yeah
I
and
like
this
is
probably
already
necessary
today,
just
to
have
same
logic
and
and
reproducible
algorithm
for
that,
but
also,
if
we're
going
to
make
it
even
weirder,
with
more
platform-less,
manifests
we're
going
to
throw
more
wrenches
into
the
gears.
I
I
have
my
hand
up,
but
I
michael
had
his
hand
up
before
and
put
it
down,
and
I
just
wanted
to
make
sure
michael
if
you
had
something
you
wanted
to
say
that
you
get
a
chance
to
otherwise
I'm
happy
to
I
mean
yeah.
G
G
You
know,
I
think,
a
lot
of
the
issues
that
we're
seeing
with
these
tags
today
with
race
conditions
with
like
customers,
not
wanting
to
allow
tags
to
be
moved
and
just
kind
of
as
you
get
more
and
more
references
for
an
image
these.
This,
like
tag-based
approach,
the
the
existing
features
we
have
in
the
registry,
make
it
really
hard
to
allow
this
solution
to
work
without
making
some
changes
to
the
registry-
and
I
think
that's
that's
kind
of
where
we're
where
we're
hitting
is
like.
G
Immutability
on
that
shot,
head
you're,
saying
yeah,
exactly
yeah,
yeah,
yeah,
and-
and
I
mean
we
could
you
know
you
could
start
some
of
the
some
of
the
registries
who
built
the
ability
for
people
to
turn
off
tag
mutability,
you
know.
Maybe
we
could
also
build
filters
on
that
tag
mutability,
but
it
just
starts
to
get
more
and
more
complicated
and
really
like.
G
G
I
guess
I
think
we
need.
We
need
additional
changes,
which
I
recognize
are
painful
for
a
lot
of
other
registries,
and
so
I'm
curious
how
we
want
to
address
that
that
disagreement.
C
I
Thanks
for
putting
this
together,
first
of
all,
I
I
do
want
to
kind
of
appreciate
that
we've
addressed
one
question
which
is
about
not
using
the
tag
listing
api
for
getting
the
signatures
through
one
index.
But
that
brings
up
the
second
question
because
there
is
a
limit
on
the
size
of
the
manifest.
So
if
we
are
to
specify
that
you
can
add
multiple
things
as
reference
types,
we
should
specify
what
happens
to
the
index
when
you
hit
manifest
that
are
not
portable
in
some
way.
I
D
I
I'll
take
that
one
I
think
four
makes
is
quite
big.
I
think
that's
what
most
registries
are
doing
right
now
and
I
would
say
it's
probably
best
to
tell
people
don't
make
enormous
indexes
or
manifest
the
problem
with
this
is
that,
if
each,
if
a
client
has
to
download
four
megabytes
before
it,
can
give
any
feedback
to
the
user,
it's
not
a
great
ux.
D
So
keeping
them
is
a
size
that
you
know
you
can
give
a
decent
ux
in
terms
of
like
response
time,
and
things
like
that,
I
think,
is
the
right
thing
to
do
there.
The
way
I
would,
I
think,
josh,
put
up
a
proposal
for
how
to
link
things
together,
although
that
kind
of
used
weak
references,
if
I
remember
correctly,
using
annotations,
I'm
not
sure
if
it's
the
right
way,
yeah,
I
I
would
say,
having
a
hard
limit
and
telling
clients
they
can't
go
bigger
than
that
is
probably
the
right.
F
F
This
thing
like
cosine
at
the
moment,
uses
like
as
manifest
at
least
groups
all
the
annotations
together,
like
it
it's
it
doesn't
put
like
in
that
case,
like
you,
wouldn't
have
the
s
bomb
annotation
and
whatever
like
prominence
annotation
or
everything
in
the
root
manifest
you
could
group
them
together
and
then
just
link
them
with
one
reference
from
the
from
the
root
index
like
it's
still
like,
I
think
for
like
a
tool.
That's
that's
pulling
in
those
values.
F
They
should
follow
up
all
the
chains
and
like
and
like
like
to
see
like
what
are
all
the
associated
pumps.
They
shouldn't
just
like
look
at
like
what's
in
the
root
index
and
stop
there.
H
H
I'm
assuming
like
most
of
putting
this
together
was
the
nesting
things
in
the
index.
But
did
you
have
thoughts
around
that
type
field
like
it
says
s-bom
in
the
example
and
how
that
relates
to
an
oci
artifact,
because
there's
the
media
type
inside
the
artifact
and
like
should
that
you
know,
should
spdx
text
slash,
spdx
or
like
something
like
that
be
surfaced
out
instead
and
then
we
rethink
what
oci
artifacts
are
or
that
just
that
type
is
duplicated
an
oci
artifact.
So
that's
question
number
one.
E
Yeah,
that's
a
good
question.
Actually
I
thought
of
that.
E
To
be
honest,
I
don't
know
if
this
proposal
goal
was
to
yeah
be
prospective
about
that,
but
yeah
that
what
was
one
of
my
fault
like?
Should
we
copy
the
config
media
type
pair?
That
would
be
a
good
way
to
yeah
to
define
that.
H
And
I
don't,
I
don't
think
in
our
other
proposals,
we
even
dived
into
that.
I
just
like
we
had
put
that
in
proposal
e,
but
didn't
really
talk
about
what
s
bomb
means,
but,
okay.
Well,
if
there
yeah,
I
think
that's
something
we
need
to
figure
out.
The
other
question
number
two
is
putting
small
data
in
the
annotations
versus
using
a
reference.
C
My
understanding
was
that
was
an
optimization
so
that
if
you
had
a
thousand
signatures
attached
to
something
you
wouldn't
have
to
go,
fetch
a
thousand
manifests
and
a
thousand
blobs
to
get
the
you
know.
Relatively
short,
you
know
1k
of
data,
correct
me
if
I'm
wrong
actual
people
who
proposed
this,
but
that
was
my
understanding
for
that.
C
That
dovetails
into
my
question,
which
was
going
to
be:
how
do
we
ensure
that
the
data
in
the
annotations
is
the
same
as
the
data
in
the
manifest
in
the
blob
and
what
clients
are
ever
going
to
fetch
that
manifest
to
get
that
blob
to
check
and
do
we
care
if
it's
different
like
like?
C
B
C
C
So
in
this
example,
in
what's
being
shared
right
now,
the
first
all
these
annotations-
oh
this
is
this-
is
an
act.
This
is
annotations
describing
signatures
on
the
am
the
arm
64
image,
which
is
actually
there
yeah,
which
is
actually
yeah.
C
F
Yeah,
I
just
had
a
follow-up
on
the
on
that
point
that
brandon
made
about
like
when
we
discussed
the
platform
unknown.
Like
did
you
see
any
problems
with
using
platform
unknown
to
to
make
sure
that
this
object
is
never
pulled
by
like
any
old
client
or
anything
like
this?
Well,
it
should
it
wouldn't
be
built
also
because
there's
there's
another
object
for
it,
that
that
that's
the
same
platform,
but
just
to
just
to
make
it
sure
like
where
you're
tossing
there.
B
I
So
one
thing
I'm
hearing
is
that
ordering
of
the
of
the
descriptors
are
important
right,
like
you,
don't
want
clients
to
order
the
signature
over
the
index
or
over
the
image
itself.
So
that
is
clearly
something
that
we
should
call
out
like.
If
things
are
getting
attached,
do
not
attach
it
on
the
top,
because
otherwise
you
end
up
having
the
problem
that
you
mentioned,
which
is
the
sorting,
would
actually
get
affected
in
some
way.
I
B
F
B
Yeah
we
we
are
hoping
that
that's
the
way
that's
going
to
work.
We
define
that
and
we
kind
of
check
when
we
add
that
to
oci.
I
don't
think
we've
gotten
far
enough
to
verify
it,
but
the
use
case
we
were
thinking
of
was,
if
you
ever
change
like
the
way
you
store
layers
or
something
like
that
and
different
clients
might
want
to
pull
different
kinds
of
layer
schemes.
A
Seems
to
me
that
the
group
is
consolidating
around
trying
to
define
these
nested
indexes
better.
C
I
mean,
I
think,
we're
I
think,
we're
focusing
on
that
here,
because
nested
indexes
aren't
well
specified
they're,
not
the
good
news
is
they're
not
used
much
in
practice.
The
bad
news
is
it's.
There
are
probably
a
bunch
of
edge
cases
in
this
algorithm,
which
is
not
officially
specified,
and
you
know
just
sort
of
organically
grown.
C
So
it's
sort
of
one
of
those
things
where
like
we
should
specify
this
anyway,
because
this
could
come
up
already,
regardless
of
you
know,
signatures
or
reference
types
or
whatever
it's
sort
of
a
thing
we
found.
That
is
a
problem
out
in
the
wild.
Today
you
could
have
a
weird
manifest.
That's
deeply
nested
and
matches
multiple
things.
C
I
think
it's
similar
to
the
etags
issue
where,
like
this
is
this
is
going
to
hit
us
specifically
soon.
If
we
go
some
of
these
proposals-
and
it's
just
an
issue
in
general
in
in
the
spec.
B
H
H
And
attach
that
maybe
every
day
does
that
mean
my
index
has
365
things
in
the
list
and
is
that
is?
Is
that
sort
of
use
case
not
gonna
work.
H
Yeah,
I
I'm
just
I'm
just
thinking
like
the
one
with
the
other
proposals
like
it
would
be
completely
supported
if
we
added
pagination
to
the
refers
thing,
api
endpoint
and
I'm
just
yeah,
I'm
just
trying
to
understand
if
that
would
even
be
supported
with
this.
If
it's,
if
it's
not
that's,
okay,
I
just
want
to
know.
D
You
have
up
to
four
megabytes
right,
so
you
can
add
things
onto
it.
So
I
think
the
thing
is
in
practice:
you'll
probably
be
updating
the
image
anyway,
if
you
care
about
the
cves,
so
is
it
realistic
to
expect,
for
example,
an
image
will
be
in
production
for
a
year
and
you'll
keep
scanning
it
and
not
change
it.
Like
there's
a
bunch,
you
know,
I
think
it
could
be
a
problem,
but
we
should
also
look
at
what's
like
what
would
realistically
happen.
H
Well,
cat
pictures
like
what,
if
I'm
just
a
weird
person
and
a
new
cat
picture
every
day,
no,
but
I
guess
the
reason
I
bring
it
up
is
like
I
had.
H
I
had
put
together
like
proposal
g
last
week,
which
is
mostly
nonsense,
but
I'm
wondering
if
the
like,
the
capabilities
of
the
index
to
support
paging
or
something
I'm
not
sure
how
that
would
work,
because
the
digest
would
change.
But
I'm
wondering,
if
that's
it.
Has
anyone
seen
anything
like
that
in
oci,
like
paging
of
indexes
or.
H
F
Again
you,
what
you
can
do
is
you
can
create
your
own
groups
either
by
like
this
at
the
station,
manifest
like
like
cosine,
does
or
or
just
by
including
new
image
indexes.
So,
for
example
like
if
you
have
360
160
like
those
those
at
the
stations,
what
you
can
do
is
you
can
create
six
manifests
and
each
one
of
them
have
60
at
the
stations
inside
there
like,
and
this
way
like
when
you're
doing
a
pool
like
you,
maybe
don't
need
like
the
whole
300
cat
picture.
F
H
F
F
If
you
wanted
to
do
the
stagnation,
then
yeah,
you
would
need
to
like
basically
split
out
the
stagnation
points
when
you're
updating
the
manifest,
like
figure
out
that,
like
okay,
this
this
object
is
getting
too
big
like
it
already
has
like
50
annotations
inside
or
sorry
at
the
station
inside
there,
I'm
not
adding
to
this
object,
I'm
creating
a
new
object.
Next
to
it
like
that,
that's
one
way,
I
would
put
this.
B
The
other
half
of
scale
ability
that
I
think
I
saw
mentioned
last
week
on
the
oci
call
was
an
individual
annotation
is
capped
by
a
lot
of
runtimes
out
there
before
kilobytes.
B
C
C
Yeah,
I
remember
that
coming
up
when
we
talked
about
specifying
a
possible
maximum
manifest
size,
I
think
we
punted
and
now
we're
just
receiving
that
punt.
On
the
other
end.
A
I
have
a
tag
question.
Maybe
I
didn't
understand
it,
and
this
proposal
doesn't
actually
reduce
the
number
of
tags.
Does
it
because
every
time
you
push
something
to
a
repo
you
have
to,
you
have
to
push
it
by
tag
and
then
update
the
index.
D
You
use
the
same
text,
so
it
reduces
it
to
one
tag.
Unless
you
have
immutable
tags,
which
I
guess
is
a
case
we
can
think
of,
but
I
mean
we
could
index
those
because
you
know
by
definition,
that,
like,
for
example,
you
can't
we
can't
write
a
tag,
so
you
could
start
with
no
index
number,
then
add
an
index
number
or
things
like
that,
and
that's
no
worse
than
the
other
solution.
A
Yeah,
but
you've
also
you've
also
added
this
thing
where
you
could
use
the
digest
in
the
tag
to.
D
Yes,
there's
two
ways
of
finding
things
right.
You
can
either
have
a
well-known
formula
where
you
can
compute
addresses,
or
you
have
a
thing
where
you
can
query
for
an
address.
This
is
proposing
using
well-known
format
formulas.
So
if
you
know
the
digest
of
an
object,
you
can
query
just
for
that
tag
and
get
the
tag
back.
We
could
also
say,
then,
if
we
wanted
to
have
immutable
tags,
you
could
say
you
know
the
digest.1.2.3
or
something
like
that.
That's
a,
I
think.
That's
that's
all.
A
C
Sanjay
said
in
chat,
I'm
really
hoping
we
don't
hit
the
tag
list
api.
I
think
I
think
in
all
of
these
cases
we're
talking
about.
We
don't
have
to.
I
think,
if
you're,
if
you're
interested
in
attachments
for
image
shot
abc,
you
can
just
get
the
like
go
see.
C
If
there
is
a
thing
tagged,
colon
shot,
256
abc
you
never
have
to
list
tags,
and
if,
if
you,
if
chris's
thing
about
the
like
1.1.2.3,
you
don't
have
to
list
all
the
tags,
you
could
just
go
see
if
there's
a
dot
one
and
if
there
isn't,
you
can
kind
of
assume,
there's
a
dot.
There
isn't
a
dot
two.
I
don't
know
if
that
is
a
safe
assumption,
but
it's
an
assumption.
One
could
possibly
make.
So
that's
so.
A
That
that
would
just
change
the
the
ux
issue
from
you
know,
listing
the
the
tags
to
some
other
way
of
describing
some
other
way
of
searching
for
what
you're.
Looking
for.
C
I
think
for
most
registries,
and
especially
because
well
because
this,
but
because
a
lot
of
these
proposals
result
in
a
proliferation
of
tags,
the
tag
list,
api
gets
harder
and
harder
to
serve
and
if
the
tag
you're
looking
for
is
at
the
end
of
the
list,
you
have
to
do
a
bunch
of
page
requests
to
get
to
the
end
of
the
list,
whereas,
if
you're
just
looking
for
you
know,
abc
or
maybe
shot
abc.1,
then
that's
like
two
requests
relatively
easy
to
find.
D
D
C
Yeah,
I
was
actually
surprised
to
find
out-
I
found
this
out
months
ago,
but
like
on
when
alpine
is
released
on
docker
hub,
it's
not
released
as
one
manifest
list
all
at
once.
It's
released
as
a
manifest
list
containing
one
image
and
then,
as
the
second
architecture
comes
out,
the
second
one
gets
added
and,
as
the
third
architecture
comes
out,
the
third
one
gets
added
and
that
there's
like
a
necessary
race
in
that
like
if
two
architecture
builds
all
right.
C
Tienen
is
here
even
to
describe
it
but
like
if
two
architecture
builds
finish
at
the
same
time,
there
is
a
race
for
that
today.
In
you
know,
regular
multi-arch
images
that
we
all
know
and
love.
C
B
That
that
was
a
question
raised.
We
were
trying
to
propose
e-tags
before,
and
I
think
we
also
were
talking
about
etay
said
that
we
wanted
to
see
some
like
distribution
or
another
reference
implementation
of
the
distribution.
Spec
show
this
could
work,
and
so,
if
we
get
some
of
those
examples
out
there
where
this
is
working,
that
would
be
a
good
good
move
forward
there.
B
I
would
want
to
know
what
clients
should
do
when
they
see
a
registry.
I
don't
know
if
they
can
tell.
If
the
registry
isn't
supporting
e-tags
can
they
tell,
and
if
so,
what
should
they
do?
When
the
registry
doesn't
support
e-tags
and
they're
trying
to
do
an
update,
do
we
need
to
flesh
out
each
of
those
scenarios.
C
You
can
you
can
tell
if
a
registry
supports
e-tags
pretty
easily
in
every
response,
it
will
include
an
etag
response,
header
or
not,
and
if
it
doesn't
as
far
as
like,
what
should
a
client
do.
In
that
case,
I
think
a
client
should
keep,
should
just
make
updates
without
the,
if,
if
not
match
header
like
there's
no
etag
to
send
back
to
the
to
the
registry,
so
it
just
shouldn't
and
it's
right,
the
client
just
doesn't
do
anything.
It
just
says.
Maybe
there
will
be
a
race.
B
F
I
So
maybe
we
don't
one
person
that
I
want
to
discuss
is
not
adding
it
in
the
specification,
but
more
like
from
a
guidance
and
an
open-ended
discussion.
So
and
it's
just
a
brainstorming
question.
What
I'm
hoping
is
that
if
I
were
to
write
a
client
tool
that
were
attaching
s-bombs,
it
would
always
attach
it
to
let's
say
an
s-bom
index
or
something
like
that.
I
That
is
just
an
index
of
an
s-pop,
and
that
has
all
the
list
of
s-bombs
and
say,
for
example,
if
you're
doing
scanning,
we
have
a
scan
index
and
we
attach
it
to
that
and
in
the
main,
manifest
entry
for
the
tag
there's
only
one
pointer,
so
it's
kind
of
grouped
by
artifact
type
or
like
some
type,
whereas
hoisted
types
like
signatures
with
that
you
want
to
access
on
on
an
optimized
basis,
can
be
in
the
main
index
as
well.
I
Does
that
seem
reasonable,
like
because
that
keeps
the
fact
that
client
tools
that
work
with
certain
types
only
need
to
touch
one
specific
descriptor
and
not
have
to
modify
every
other
portion
of
the
of
the.
B
I
Right
right,
it
is
two
puts
in
some
way,
but
it's
still
kind
of
like
at
least
gives
away
in
which,
if
I'm
not
interested
in
spam,
I
don't
walk
that
that
train
or
or
you
have
to
kind
of
like
make.
Every
client
know
about
how
the
entire
manifest
needs
to
be
updated.
I
D
I
think
the
oci's
role
is
not
to
define
what
is
stored
complete
at
that
level
of
detail.
I
think
it's
just.
It
provides
the
building
blocks
to
build
the
things.
I
think
clients
should
not
assume
that
everything
like,
for
example,
there's
only
s-bombs
in
there,
because
there'll
be
images
there'll,
be
there's
no
guarantee
that
other
clients
haven't
put
up
data
as
the
spec
is
written
today.
There's
no
guarantee
that
if
you
pull
down
a
manifest
list,
it's
only
images
right.
It
could
be
I'll
pick
on
toner,
so
it
could
be
build
cache.
D
It
could
be
something
else
like
and
that's
just
how
the
spec
is
structured.
It's
that's
just
that's
just
how
it
is
right
and.
I
So,
that's
why
it's
not
a
question
of
the
specification
itself,
it's
more
like
if
you
come
and
ask
the
oci
team,
how
do
you
do
this?
What
would
be
at
least
a
verbal
guidance,
or
how
would
you
help
them
out
right?
I
D
I
think
it's
more,
you
come
and
say
I
have
scan
results,
and
so
I
think
I'm
going
to
attach
them.
The
oci
will
say
that
looks
like
it
fits
a
spec
or
not.
I
don't
think
that
they
will
say
like
this
is
the
way
of
define,
observe,
attaching
scan
results,
or
this
is
the
way
of
attaching
s
bomb.
This
group
is,
I
think,
from
what
I
understood
just
about
a
generic
attaching
of
things
the
what
things
is
a
separate
conversation
I
think,
and
I'm
not
sure
the
oci
will.
H
B
I
don't
think
it's
going
to
break
the
specification
and
you
can
make
it
easily
searchable,
because
your
top
level
index
would
say
this
is
the
s
bomb
index
if
you're
looking
for
an
s
ball
and
go
down
this
path,
it's
just.
If
we're
trying
to
eliminate
those
race
conditions
and
you
go
down
update
the
s
bomb
index,
you
still
have
to
come
back
up
and
update
the
top
level
index
and
so
you're
still
racing
on
that
top
level
index.
In
addition
to
the
s
bomb
index,
if
someone
updates
the
second
s
bomb.
C
If,
if
you
got
you
know,
it
doesn't
have
to
be
because
there
are
too
many
it
can
be
because
you
just
want
to
file
them
in
this
way,
and
you
put
your
s
bombs
in
the
first
one
and
your
attestations
in
the
second
one
and
whatever
the
problem
is,
when
you
assign
semantics
to
those
buckets
and
say,
if
you're
looking
for
an
s-bomb,
only
look
in
the
first
one
or
only
look
in
the
one
named
s-bomb
or
something
because
some
other
client
who
isn't
you
a
badly
behaved
client
that
I
probably
wrote,
probably
put
the
s-bomb
in
the
last
one,
and
so
you
can
shard
and
move
and
rebalance.
C
C
I
think
we
can
specify
that
order
matters,
because
order
is
a
much
easier
thing
to
semantically
describe
like
we
all
understand
what
order
means,
but
we
don't
understand
what
an
s
bomb
means.
I
think
we
we,
I
think
we
can
say
when
sharding
the
original
order
has
to
be
preserved.
Somehow
I
also
realize
we're
at
time
now.
So
I'm
sorry,
if
you
want
to,
if
you
had
more
to
talk
about
I'm
happy
to
stick
around.
H
A
So,
let's
see
it
seems
to
me
that
folks
are
okay
with
working
on
this
nested
index
thing.
Did
I
get
that
right.
C
I
mean
I'm
certainly
interested
in
talking
about
it.
I
don't
know,
I
don't
know
if
I
have
personally
like
like
come
to
peace
with
it,
but
I
think
there
I
think,
understanding
the
you
know.
Potential
problems
with
it
in
in
practical
usage
is
a
useful
thing.
Whether
or
not
we
proceed
down
this
path
and
I
think
we're.
A
Yeah
I
mean
I
I
feel
like
at
least
personally.
I
started
from
the
position
that
you
can't
touch
this
like
this
is
verboten,
but
if,
if
the
group
is
open
to.
A
H
The
purpose
of
the
proposals
is
not
all
right.
Here's
proposal
f,
let's
roll
with
it
right,
it's
you're
gonna,
throw
it
up
we'll
have
these
conversations.
I
would
hope
that
we
maybe
figure
some
of
these
out
have
a
proposal
g.
Maybe
it's
based
up
primarily
on
proposal.
F.
If
we
agree
on
it,
but
yeah,
don't
don't
look
at
these
as
like
we're
gonna
pick
one.
I
think
that's
that's
at
least
the
way
I've
been
thinking
about
it.
A
Well,
I
I
mean,
I
think,
we've
changed,
I
I
know
we're
over
time.
Maybe
I'll
pick
this
up
next
meeting,
but
I
feel
like
we've
kind
of
changed
the
the
requirements.
C
A
Yeah,
that's
a
better,
that's
a
better
wording
for
that
we've
like
expanded
some
possibilities.
I.
C
Think
what
we
want
to
produce
is
still
roughly
the
same,
but
if
folks
from
docker
are
interested
in
making
sure
that
nested
indexes
are
handled
correctly,
then
like
that
opens
that
up
for
a
lot
of
us
which
we
didn't
have
before
but
yeah.
I
also
I
also
have
to
drop.
This
was
a
really
good
meeting.
Everyone
nice
work
high
five
best
meeting
of
the
week
so.