►
From YouTube: [OCI-WG] Reference Types - 2022-04-05
B
B
B
B
Yeah
yeah,
no,
it's
it's
lovely!
I
like
it
here.
D
B
Yes,
please
hydrate.
C
Yeah
I
have
made
that
with
some
chai
spices
and
it
tastes
just
awesome
and.
B
D
C
There's
definitely
a
lot
of
cinnamon,
but
the
indian
side
will
add
a
lot
of
cardamom,
so
all
smells
and
tastes
very
good
love.
It.
B
B
E
I
can
the
second
pick.
E
B
B
B
E
D
B
B
Excellent
thumbs
up
all
around
hello,
yes,
hello,
okay,
excellent
hello
and
welcome
to
the
oci
working
group
for
reference
types
today
is
tuesday
april
5th.
I
hope
everybody's
having
a
wonderful
day,
just
a
reminder
that
this
meeting
is
being
recorded
and
will
be
posted
to
youtube
and
falls
under
the
code
of
conduct
for
the
oci.
So
it
basically
says
please
treat
everybody
with
respect
in
all
that
you
converse
and
write
down.
I
would
really
appreciate
it
if
we
all
adhere
to
that.
I
have
posted
the
hackmd
link.
B
I
will
do
it
again
for
those
that
just
joined,
please
add
your
name
to
the
attendees
list
there.
I
am
lachlan
evans
and
I
will
chair
this
meeting
today
and
we
have
jason
hall
as
the
note
taker
with
the
gold
medal.
Thank
you
very
much
jason
lovely
to
see
all
the
faces
here
today.
We've
got
a
packed
agenda
again
today,
we're
going
to
we
have
two
items.
We
have
review
proposal
a
and
with
sanjay
and
suggestion
for
proposal
e
with
brandon.
B
So
to
kick
us
off
today,
sergey,
I
will
hand
you
the
proverbial
microphone
and
the
little
soapbox
put
it
under
your
feet.
You
have
proposal
a
which
you
can
share
with
everybody.
Thank
you,
sergey.
G
Hey
do
folks
have
links,
or
do
you
want
me
to
share
the
link
for
proposal
as
well
I'll.
B
B
G
All
right
can
folks
see
we
see.
Thank
you
sergey
right.
I
want
to
thank
steve
for
submitting
this
the
whole
proposal.
So
how
do
you
want
me
to
walk
through?
Should
I
just
go
part
by
part
or
do
folks
have
any
questions
that
I
can
answer
up
front.
B
G
Sounds
good
so,
let's
start
with
the
one
of
the
key
requirements
where
we
considered
a
different
set
of
options
like
the
primary
consideration
was
to
change
the
oci
manifest
itself.
There
were
limitations
in
how
we
could
kind
of
like
remove
requirements
for
config
and
also
we
just
wanted
to
kind
of
like
start
clean
to
start
with.
G
So
the
proposal
in
its
current
state
is
a
is
a
representation
of
what
rs
has
done
to
for
many
extent,
but
want
to
look
at
it
for
the
working
type
groups
and
how
this
kind
of
aligns
with
the
oci
requirements
going
forward.
So
just
to
start
with,
the
first
requirement
was
to
kind
of
like
identify
what
is
being
pushed
to
the
registry.
G
G
The
second
part
was
how
how
we
wanted
to
kind
of
like
stitch
together
different
types
of
artifacts,
so
it
kind
of
takes
from
the
concept
of
layers
for
the
oci
image
spec.
But
the
difference
is
that
there
is
no
ordinal
requirement
for
these
blobs
to
exist,
like
layers
have
to
be
have
to
be
ordinal
in
some
way
and
they
kind
of
compose
over
the
defides
and
whatnot.
G
G
So
those
were
the
two
key
aspects
of
why
we
did
not
want
to
kind
of
like
choose
layers
and
kind
of
like
keep
it
as
blobs,
but
there's
nothing
stopping
us
from
evolving
it
to
just
collet
layers,
but
it's
not
ordinal
when
maybe
a
property
specified.
That's
that's
one
of
the
key
aspects
of
this
one.
The
most
important
property
here
that
we
want
to
discuss
was
the
subject
itself.
G
The
subject
is
a
pointer
to
another
artifact
or
another
entry,
which
is
a
manifest
in
this
case,
which
is
the
digest
of
the
manifest
with
this
media
type,
because,
as
everybody
knows,
the
registry
kind
of
like
modifies
the
digest,
depending
on
the
media,
type,
that
you
actually
query
it
with
right.
G
So
you
want
to
give
the
full
descriptor-
and
this
is
very
similar
to
what
the
other
proposals
have,
which
is
introduce
a
reference,
and
so
we
could
call
it
reference
or
subject
the
reason
why
we
went
with
subject,
I
think,
is
also
an
interesting
thing,
because
it's
it's
kind
of
pointing
upwards
in
some
way,
but
as
references
kind
of
point
downwards,
we
could
kind
of
like
keep
it
as
a
reference
to
the
subject.
It
really
doesn't
matter.
G
A
couple
of
other
considerations,
maybe
was
whether
you
should
support
one
subject
and
multiple
subjects.
So
for
the
purpose
of
time
we
can
talk
about
that.
If
folks
are
interested
in
hey,
can
I
have
one
artifact
pointing
to
multiple
images
like
can
I
have
a
bundle,
signature
and
things
like
that,
but
just
to
kind
of
start
off
with
we
considered.
G
Let's
start
with
one
subject:
you
can
create
a
link
file
and
then
kind
of
like
build
on
that,
so
the
other
consideration
for
subject
was
if
we
ever
wanted
to
keep
these
properties
generic
enough,
and
you
wanted
to
expose
more
ideas.
I
think
this
kind
of
came
back
from
vincent's
feedback,
which
is,
let's
assume
we
want
to
point
to
blobs
at
some
point.
G
We
don't
have
to
change
this
from
manifest
to
descriptors
or
something
else.
So
that's
why
the
name
is
open
enough,
but
yet
it
does
not
kind
of
like
the
specification
can
still
start
with
just
manifest
and
maybe
later
revolve
use
a
property
name.
That
is
a
little
generic.
That
was
the
idea,
I'm
not
seeing
any
up
yeah
random.
I
see
I
am.
D
Yeah
just
do
that
up,
you're,
saying
you're
gonna
allow
subjects
to
be
a
blob
in
the
future.
Is
your
thought.
G
G
That's
that's
kind
of
like
the
the
initial
pitch
that
when
we
discussed
with
vincent
whether
we
want
to
take
this
forward,
it
was
initially
called
manifest,
and
then
we
kind
of
like
went
for
a
couple
of
iterations
and
in
the
current
proposal
is
subject
just
to
kind
of
like
indicate
whether
we
want
to
choose
names
that
are
possible
for
future
expansion
without
kind
of
closing
the
name
itself.
D
I'll
push
back
for
two
reasons:
to
cut
off
future
people
to
think
about
this
option,
which
was
one
you
might
create
the
option
for
looping
in
that
case,
because
you
could
potentially
point
to
a
blob
that
you're
also
pointing
to
as
your
child,
and
you
can
get
that
looping
scenario.
D
G
F
Yeah,
I
think
we're
there's
two
pieces
wrapped
in
there
there
was
the
subject
property
and
whether
it
can
point
to
blobs
or
manifest,
and
we
did
land
on
manifest
because
it
is
a
thing.
Basically
we're
trying
to
point
out
an
object
that
has
a
life
cycle.
Blobs
are
an
implementation
of
a
manifest,
so
it
the
thing
that
I
think
we
got
is
the
blobs
collection
was
going
to
be
possibly
descriptors
so
that
it
could
contain
other
manifests
as
well
as
blobs,
and
that's
the
one
that
definitely
provided
loops.
F
So
we
we
backed
out
of
that
there
was
actually
a
pr
that
was
in
the
main
repo
and
then
we
backed
back
out
because
we
weren't
comfortable
with
implementing
that
change.
So
a
subject
points
to
a
single
manifest,
not
a
blob
and
the
mat.
The
blobs
collection
is
literally
blobs
that
represent
the
reference
type.
If
it's
a
signature,
it
contain
content.
If
it's
a
nest
bomb
could
contain
content
and
I'm
sure
we'll
get
into
the
area
where
we
don't
actually
need
blobs.
It
could
just
be
a
set
of
annotations.
D
Yeah,
the
the
looping
risk,
though,
is
anytime
that
your
subject
can
point
to
something
that
is
also
one
of
your
child
objects
from
other
fields.
In
that
same
manifest,
and
so
you
need
to
keep
those
a
dif,
you
need
to
keep
the
subject
at
a
higher
level
than
every
other
descriptor
in
within
that
manifest
completely.
F
G
Right
so
so
that's
that's
about
the
manifest
itself,
and
then
this
is.
I
would
kind
of
like
qualify
this
as
a
slightly
hairy
topic,
but
it's
worth
discussing.
That's
why
I
wanted
to
pre-qualify.
G
We
did
want
to
introduce
a
descriptor
with
an
artifact
type
in
this
proposal.
The
reason
is
that
we
want
to
use
this
type
as
a
way
when
you
communicate
back
the
list
of
references
to
tell
you
that
it's
not
just
an
oci
artifact,
you
want
it
to
kind
of
like
say
that
it
could
be
an
artifact
of
a
signature,
type
and
whatnot.
We
can
move
this
to
an
annotation
as
a
part
of
the
working
group.
G
If
we
agree
that
no,
we
just
want
to
keep
the
descriptor
as
is,
and
not
introduce
a
new
property
as
well
brandon
go
ahead.
D
G
And
and
if
the
working
group
can
come
up
to
and
agree
that
okay,
we
can
use
something
like
open,
container
start
or
artifact
type
or
something,
then
it
makes
the
whole
conversation
much
more
simpler
and
it's
a
standardized
one
and
the
proposal
also
improves
in
some
way.
F
D
I
was
going
to
push
to
have
it
all
annotations
and
to
kind
of
do
that
propagation
up
from
whatever
your
manifest
is
to
propagate
up
all
the
annotations
on
that
manifest
to
whatever
descriptor
you
return,
and
that
way
you
can
filter
on
more
than
just
your
one
field.
If
you
need
to
on
the
client
side.
F
So
we
explored
that
a
little
bit
and
there
was
a
concern
about
how
many
annotations
would
come
up
and
what
is
the
the
validation
of
that
like
do?
We?
Is
it
just
manifest
annotations?
Is
it
the
blob
annotations
as
well?
So
that's
the
circle
around
which
annotations?
Is
it
a
special
case
annotation
or
a
new
property.
D
G
Let
me
get
to
the
reference
api
or
the
actual
api
that
returns
the
lists,
and
this
the
reason
of
why
this
exists
might
become
a
little
more
clear.
But
I
think
these
are
just
flexible
points
that
we
need
to
discuss
as
a
part
of
the
working
group
and
agree
all
annotations
are,
or
none
or
maybe
a
property
or
whatever.
That
is
so.
This
is
probably
the
most
interesting
part
of
the
api,
which
is
how
do
you
get
the
list
of
references
that
are
attached
to
an
image
or
an
artifact
or
whatnot?
G
So
the
the
similar
apis
have
been
discussed
before
and
I
don't
think
the
shape
is
any
different
from
what
we
have
discussed
earlier,
which
is
the
api
is
based
on
the
digest
because
the
tags
are
mutable
and
what
not.
So
as
long
as
you
have
the
digest,
you
kind
of
query
by
the
digest,
we
went
through
a
couple
of
different
rounds
of
api
discussion.
G
The
idea
is
that
you
query
for
the
reference
and
you
give
it
the
digest
off
the
of
the
artifact
that
you're
quitting
for
and
that's
it,
it's
very
similar
to
how
tag
listing
api
and
everything
else
works,
and
you
kind
of
like
use
the
same
pagination
semantics
for
tag
api
and
the
response
is
nothing
but
a
set
of
descriptors
and
each
of
the
descriptors
here
have
the
corresponding
digest
of
the
artifact,
followed
by
its
media
type
and
size,
just
for
validation
as
a
standard
response
jason.
You
have
a
question.
E
At
the
risk
of
bike
shedding,
but
then
that's
what
we're
here
for
what
is
the
artifacts
part
in
the
path
for?
Could
it
just
be
underscore?
Oci
refers.
G
We
can
the
that's
that's
just
following
the
current
oci
extension
specification,
so
we
can
change
it
to.
We
can
maybe
work
on
the
extensor
specification
and
talk
to
vincent
as
well
to
kind
of
remove
that
as
well,
but
this
is
just
aligning
with
that
as
a
path
it's
not
set
installed.
B
E
G
We
could
propose
both
ways
right,
depending
on
what
distribution
accepts.
We
could
say
that
if
you
don't
allow
us
to
sit
directly
under
distribution,
we
could
start
as
an
extension,
see
it
getting
adopted
and
then
move
it
up
with
2.0
or
3.0
distribution.
It's
up
to
us
to
kind
of
make
that
decision,
but
this
is
just
a
start
point
of
the
other
thing.
Maybe
I
can
give
some
context
on
why
the
name
was
kind
of
like
discussed.
G
This
way
was
oci
is
the
name
like
the
grouping
of
all
extensions
that
oci
can
pro
kind
of
like
incubate
under,
and
this
one
is
mostly
like
what
we
discussed
as
a
component
or
a
sub
component,
so
different
ways
to
kind
of
link
different
artifacts.
We
could
say
this
is
ref
types,
slash
reference
if
you
want
to,
if
that's
the
working
group
that
we
want.
G
So
it's
up
to
us
to
kind
of
like
call
it
whatever
or
whatever
the
name
should
be
so
yeah,
so
that
might
help
the
last
one
is
that
we
decided
to
move
everything
to
arguments
just
to
keep
this
path
as
simple
as
three
parts,
which
is
the
name
the
working
group
or
the
group
followed
by
the
actual
operation
and
everything
else,
kind
of
goes
as
arguments
and
the
digest
is
nothing
but
the
argument
of
the
manifest
itself
any
questions,
because
I
think
that
kind
of
covers
that
of
the
gist
of
it.
G
C
Yeah
thanks
I'll
start
from
the
top.
You
said
that
the
blobs
don't
have
to
be
ordinal.
Is
it
possible
to
enforce
blobs
being
ordinal.
G
F
That's
kind
of
up
to
the
artifact
type
right.
This
is
the
whole
idea
that
layers
are
ordinal,
because
it
makes
sense
for
the
container
image
format,
helm,
charts,
they're,
not
signatures,
may
not
that's
problems.
Probably
not
the
whole
idea
is
that's
really:
it's
a
collection
and
it's
up
to
the
artifact
type
to
decide
what
they
want
to
be.
There.
G
Right
and
the
order
of
the
blobs
cannot
change,
because
the
manifest
would
change.
Then
the
digest
of
the
manifesto
change
so
how
the
blobs
are
listed,
is
indirectly
bound
and
how
the
manifest
is.
Formatted
is
indirectly
bound.
So
there's
not
too
much
of
an
issue
with
the
ordinality
itself,
whether
you
use
it
and
you
mount
it
as
a
flat
file
system
without
write-out
files
or
whether
you
use
it
as
a
a
set
of
files
that
are
individual
files
is
up
to
you.
G
That
was
the
reason
why
the
whole
idea
was
to
kind
of
like
step
away
from
the
layers,
whereas
layers
require
them
to
be
composed
in
a
particular
way.
An
image
spec
has
a
notion
of
how
the
layers
need
to
be
used,
but
there's
nothing
stopping
us
from
saying
yeah.
We
use
the
same
layers.
G
C
Yeah,
I
have
a
list
of
questions.
I
was
noting
down
questions
while
you
were
going
through
things,
but
okay
can
the
subject
point
to
another
artifact
manifest.
G
C
C
So
you
can
have
like
a
application
vendor
ci
artifact,
manifest
that
has
a
subject
which
also
has
a
vendor
oci
artifact
manifest.
So
there
might
be
a
loop
over.
There
is
similar
to
the
other
proposals
that
have
references.
D
D
C
Okay,
so
suppose,
there's
a
blob
that
points
to
a
signature
and
the
subject
also
points
to
the
signature.
What
happens
then.
F
F
F
C
Okay,
so
my
next
question
is
this
looks
like
a
v3
change
like
a
major
version
bump.
C
Why
is
it?
Why
did
you
choose
to
use
v2.
G
So
this
is
a
part
of
the
oc
extension
discussion
that
we
had.
The
spec
actually
allows
you
to
expose
new
apis
under
v2
without
going
through
a
full
v3
rep,
primarily
because
authentication
and
all
that
works
very
similar.
For
example,
if
you
can
pull
an
image,
you
want
to
be
able
to
use
the
same
scope
to
be
able
to
access
and
the
moment
you
kind
of
go
to
v3.
You
have
to
have
different
routing
rules
and
whatnot,
and
that
makes
the
registry
hosting
a
much
more
difficult.
G
So
that
was
the
that
was
the
reasoning
why
it's
under
v2
the
manifest
itself
is
an
image
specification
detail:
it's
not
a
detail
of
the
registry,
so
the
registry
enables
you
to
expose
a
v2
api
through
the
extension
api,
but
you
can
have
manifests
that
are
not
specifically
in
the
v1
of
image.
Spec.
That's
the
reasoning.
Does
that
explain
why
it's
under
v2.
G
So
if
you
kind
of
like
look
at
look
at
this
one,
maybe
you
can
follow
that
as
a
way
to
kind
of
like
see
the
extension
proposal
which
enables
you
to
add
more
to
v2
without
actually
breaking
clients.
C
Okay,
so
the
fact
that
there
is
a
new
path
to
refer
to
artifacts
helps
to
distinguish
between
registries
that
support
the
artifact,
manifest
and
registries
that
don't.
F
G
C
Okay,
so
next
question,
I
I
didn't
quite
understand
why
the
descriptor
needs
to
also
have
an
artifact
type,
along
with
the
manifest
is.
Is
that
to
reduce
like
round
tripping
when
you're
querying
things.
G
Right
you,
I
think
you
kind
of
like
hit
the
nail
on
the
head.
The
whole
idea
was
that,
if
you
did
not
filter
on
the
server
you
send
back,
let's
say
you
have
100
signatures
or
a
hundred
something
in
links
to
that
specific
image.
You
get
back
a
full
list
of
something
just
by
looking
at
this
media
type,
you're
not
going
to
be
able
to
tell
what
it
is.
G
You
have
to
kind
of
go
back,
so
I
I
I
kind
of
here
take
away
two
proposals
here,
which
is:
let's
drop,
the
artifact
type
and
maybe
use
an
annotation
or
just
give
all
the
annotations
of
the
manifest.
That's
that's
one
possible
option
where,
when
we
put
together
a
proposal,
we
can
kind
of
like
massage
this
and
say
look
at
the
annotations
to
define
what
the
artifact
is.
That
was
the
basic
reason.
G
Otherwise
you
have
to
go
back
and
pull
everything
on
the
image
which
might
be,
if
you're,
having
daily
scans
you're,
going
to
have
365
scans
by
the
end
of
the
year
or,
if
you're,
having
signatures
that
is
signing
on
a
regular
basis.
You'll
have
more
of
that
kind
of
craft
coming
in.
So
it's
more
like
an
optimization
mechanism,
nothing
more.
F
We
basically,
we
did
a
two-phase
approach
is
basically,
you
can
filter
on
artifact
type,
which
is
actually
optional
in
the
spec,
and
you
can
go
further
and
filter
on
annotations.
The
idea
is,
annotations
are
more
complex
to
index
all
of
them.
So
the
idea
is
you
filter
on
a
single
artifact
type
property.
It
makes
implementations
easier
to
manage,
so
that's
that's
kind
of
why
it
was
lifted
as
a
first
class
property.
D
And
steve,
I
know
you
were
bringing
this
up
earlier
you're
asking
if
we
start
lifting
these
things
up
as
annotations.
Where
do
we
stop
and
I
would
say,
stop
when
you
have
when
you
hit
that
first
manifest,
don't
dig
into
the
child
of
the
manifest
and
other?
You
know
blobs
and
things
like
that.
Just
pull
up
those
first
layer
of
artifacts
of
annotations.
F
F
H
Yeah
yeah,
I
mean,
I
think,
one
of
the
things
about
that
is
it.
You
know
you
quickly
get
into
the
spot
where
you
could
be
lifting
up.
Almost
all
of
the
data
of
the
manifest
right.
The
annotations
is
unbounded,
and
I
think,
alongside
of
this
proposal,
there
was
the
talk
that
was
recently
merged
of
adding
that
data
field,
and
so,
if
you're
going
to
lift
all
of
the
annotations,
which
is
potentially
you
know,
3.9
megabytes
of
manifest
or
something.
H
C
I
have
one
last
question
and
this
one
you
know
coming
from
someone
who
is
not
an
api
expert,
but
there
are
some
folks
that
I've
spoken
to
who
have
said
that
having
parameters
in
the
api
may
not
be
a
good
idea,
just
real
quick
just.
Why
did
you
choose
to
use
parameters
rather
than
full
paths.
G
I
can
give
some
history
on
this.
If
folks
are
interested,
we
went
through
the
original
reference,
slash
reference,
because
if
you
implement
distribution
they
actually
have
a
reverse
segment
lookup,
which
is
you
look
at
the
path
and
then
you
kind
of
walk
back.
There's
some
really
interesting
implementations
that
you
can
do
where
you
just
pass
in
the
digest,
followed
by
referrer,
slash
and
give
me
references.
That
is
one
way
to
do
it.
G
We
went
through
that
full
cycle
and
then
we
went
through
the
extensions
proposal,
which
is
have
a
standard
way
in
which
you
can
extend
the
registry
and
move
everything
to
parameters.
So
that
was
the
flow
of
thought
and
a
bunch
of
conversations
on
the
extension
pr
kind
of
like
call
out
why
we
didn't
do
that.
I
don't.
I
haven't
seen
an
issue
with
parameters,
because
the
registry
already
expects
things
like
next
and
there
is
a
last
tag
and
all
that
that's
already
there
on
distribution.
G
So,
that's
not
to
me
a
security
concern
yet,
but
if
there
is
maybe
we
should
talk
about
it,
I
mean
that's
just
from
my
side
that
I
can
comment
if
others
have
any
other
things
to
add.
Please
do.
E
Yeah
I'd
be
curious
to
I'd,
be
curious
to
know
more
about
why
parameters
are
considered
more
dicey.
I
I
think
they're
more
or
less
the
same
like
whether
the
values
are
dollar.
Sorry,
sorry,
ampersand,
a
equals
b
or
a
slash
b.
I
don't
think
it
really
matters
url
parsing
is
is
pretty
standard
and
well
understood.
Hopefully,
at
this
point,
hopefully.
E
Yeah,
my
question
was
more
and
I
think
I
brought
this
up
in
the
pr
as
well
there's
a
requirement
that
the
subject
when,
when
a
artifact
references,
another
thing
as
a
subject
the
spec
this
this
spec
proposal
says
that
subject
must
exist.
I
was
wondering
if
there
was
a
technical
reason
that
is
the
case
like
or
if
there
is
an
implementation
reason
that
you
need
that
to
be
the
case
or,
if
that's
more,
of
a
philosophical
argument.
G
I
think
I
was
on.
Actually
I
was
on
the
fence
of
that
one,
I'm
okay
relaxing
that
requirement,
because
otherwise
you
won't
be
able
to
push
the
signature
before
you
push
the
image,
and
things
like
that.
I
think
that's
a
very
fair
ask
and
for
specifically
for
offline
signing,
we've
been
kind
of
thinking
about
that.
G
The
reason
why
we
started
with
the
subject
should
be:
there
is
just
to
keep
it
simple
to
start
with,
and
then
we
can
kind
of
evolve
that
so,
as
a
working
group,
we
can
decide
that
the
proposal
does
not
have
the
requirement
and
to
support
these
scenarios.
We
remove
this
section
or
like
remove
that
requirement
all
the
way.
The
challenges
it
brings,
however,
is
how
long
do
you
keep
that
if
they
never
push
the
image?
G
Those
are
things
that
registries
might
have
to
absorb
in
some
way
saying
that
you
push
the
signature,
but
you
have
some
policy
and
that
can
be
an
implementer's
detail
and
not
on
the
not
in
the
specification
itself.
So
it
keeps
the
specification
simple
enough,
michael,
if
you
have
you
can
add
to
that.
Maybe.
H
H
Yeah,
these
are
definitely
different,
but
yeah.
That
was
a
pattern.
D
It's
recommended,
but
it's
not
required
by
oci.
Today
it
is
suggested-
and
I
would
say
that
one
option
for
the
gc:
if
there
are
users
that
have
used
cases
where
they're
worried
about
that
they
can
just
tag
their
artifact.
E
Yeah,
I
think,
sanjay
to
your
point
about
we
should
well
if,
if
we
don't
require
the
subject
to
exist,
when
you
refer
to
it,
we
should
be
meaningfully
vague
about
what
that
means
for
garbage
collection,
in
the
same
way
that
we
are
meaningfully
vague
about
garbage
collection
in
general,
because
we
don't,
you
know,
specify
it
at
all,
but
I
think
there's,
I
think,
there's
use
cases
that
are
enabled
by
not
requiring
it,
though
I
do
understand
that
the
you
know
the
pragmatism
of
keeping
some
flexibility
to
change
later.
E
G
I
totally
agree
and
I
think
from
the
specification
standpoint,
we
don't
have
to
call
out
exactly
what
the
behavior
should
be,
but
if
there
is
a
use
case,
maybe
we
should
write
so
call
out
that
to
push
the
signature,
you
want
to
do
that
first
before
you
push
the
image,
so
there
has
to
be
a
way
to
support
that,
but
this
is
at
this
point:
it's
it's
a
very
open
discussion.
E
Yeah
my
main
question
was
was:
was
there
a
a
technical
reason
you
needed
this
to
be
the
case
or
like
we,
you
needed
to
make
a
decision
and
you
made
a
decision.
If
it's
the
other
one,
then
we
can
like,
then
I
can
debate
and
if
it's,
if
it's
some
technical
reason,
then
I
can't
so.
No
that
I
don't
know.
F
F
Can
I
because
we
went
through
this
quite
a
bit
as
well
as
if
you
can
push
an
update
to
a
tag,
so
I
have
a
v1
image
and
I
want
to
push
an
update
to
the
v1
tag
because
there's
a
security
update
if
I
have
to
push
the
image,
that
is
a
v1
image,
a
new
v1
image
and
I
want
it
to
be
signed.
Well,
these
are
separate
documents,
so
I
first
push
the
new
v1
image
and
then
I
push
the
signature
of
the
signatures
attached
signature.
F
F
The
there's
two
ways
we've
thought
about
fixing
you
know
doing
that
and
it's
actually
available
in
the
apis
today.
Is
you
actually
push
the
new
manifest
as
a
digest?
You
don't
actually
push
the
tag,
so
you
push
the
new
manifest
as
a
die,
is
a
unique
digest.
So
it's
a
new
artifact,
it's
a
new
image,
but
it
has
no
affiliation
with
the
tag.
Yet
you
push
the
signature
that
points
to
that
digest
and
then
you
push
the
tag
update.
That
says.
V1
now
points
this
new
digest
and
then
the
alert
goes
off.
E
F
In
theory,
yeah
most
registries
that
I
know
have
done
untagged
digests,
don't
do
it
immediately.
It's
a
you
know
things
that
are
over
some
period
of
time
sure.
So
if
it's
a
push
operation
because
most
that's
the
whole
concept
of
why
it's
garbage
collection
versus
just
validation,
right,
there's
a
latency
in
there
that
gives
the
registry
time
to
coalesce
the
various
push
operations.
E
Yeah,
I
think,
there's
also
a
use
case
on
the
other
end
of
the
lifecycle,
where
you
know,
I
may
not
want
to
store
the
image
that
I
was
running
six
years
ago,
but
I
would
want
to
store
the
people
that
signed
it.
The
signature
data
of
the
people
that
signed
that
image.
If
in
case
I
needed
to
go
back
and,
like
you
know,
do
some
forensics,
I
might
not
want
to
store
that
image,
I'm
never
going
to
run
it
and
it
costs
money
to
store.
E
F
You
pointed
out
the
inconsistency
on
this
just
to
finish
that
loop
and
a
handoff,
but
it
was
on
delete
you
may
I
care
exactly
how
it's
worded,
but
when
you
delete
the
v1
tag,
you
can
decide
to
leave
signatures
around.
So
there
is
a
little
inconsistent
that
the
subject
must
exist
when
you
push,
but
you
can
delete
and
leave
this
the
signature
or
s-bomb
around
if
you
wanted.
That
was
the
the
balance
to
that
pr.
D
E
So
it
may
I
mean
this
this.
This
goes
to
an
issue
that
we
have
sort
of
conceptually
about
what
tags
are
for
our
tags
for
human.
You
know
human
semantic
understanding
of
what
this
thing
means
like
this
is
b1.2.3,
or
is
this
I
or
are
we
saying
the
tag
exists
to
prevent
the
garbage
collector
from
deleting
it?
E
H
Is
a
game
there?
I
would
say
for
life
cycle
management
like
we.
If
you
scroll
down
there
is
we
have
a
blurb
on
that,
and
it
just
says
that
registries
may
tie
the
life
cycle
so,
like
registries,
can
clean
up
tags
that
are
sorry
signatures
that
whose
subjects
are
deleted,
but
they
don't
have
to
so
you
know
you
could
imagine,
like
a
free
registry
may
do
something
different
than
a
private
registry
would
do
or
even
within
a
private
registry
it
could
be
configurable.
H
I
also,
I
also
think
like
if
you're,
if
you
need
to
keep
around
these
references
there,
there
are
possibly
other
ways
to
do
this
other
than
leaving
them
in
your
production.
Repo.
E
H
E
Everyone
meeting
adjourned.
H
E
That's
fair,
I
I
apologize
for
my
flippant
answer,
but
I
I
think
that
I
think
yeah.
G
I
Thanks
sergey
hey,
so
I'm
curious
with
the
new
manifest
type.
I
I
Is
there
a
scenario
we
can
support,
where
images
could
actually
be
the
subject
of
something
else?
There's
like
been
an
ongoing
discussion,
for
example
in
helm.
Where
can
we
make
like
images
of
first
class?
G
My
take
is
no
images
have
a
good
definition
already,
but
the
discussion
does
exist.
G
Whether
this
is
the
one
manifesto
rule
them
all
kind
of
thing,
but
I
want
to
focus
on
the
fact
that
we're
solving
a
specific
problem
here
so
changing
the
image
manifest
was
not
the
scope
of
the
group
so
that
the
conversation
I'm
leaning
towards
is
this
is
about
solving
being
able
to
attach
new
things
that
are
not
images,
and
so,
if
we
are
open,
I
think
we
can
open
the
conversation,
but
that's
what
I
would
vote
if
asked,
should
we
change
the
image
manifest,
but
we
can
represent
an
image
if
you
want
to
the
second
question
whether
images
can
point
to
other
images
that
would
lead
to
proposal
the
previous
proposal,
which
is
adding
a
reference
to
the
image
spec
itself.
G
That
way,
you
can
have
an
image
point
to
another
image,
but
I
don't
know
beyond
that,
and
others
have
opinions
please
or.
F
I
Yeah,
like
so
using
your
references,
sorry,
let
me
pull
it
up
here
using
the
refers
endpoint.
Could
I
do
point
to
the
hash
of
a
helm
chart
and
be
like
nginx
and
prometheus.
G
G
I
Sense
yeah,
I
guess
the
the
reason
I
bring
up
like
the
first
question
is:
if
the
subject
field
is
not
applicable
to
images
and
you're,
saying
that
images
shouldn't
use
this
manifest,
then
that
relationship
seems
to
be
not
doable,
which
is
which
is
fine,
I'm
just
I'm
just
trying
to
understand.
That's.
F
F
We
just
go
back
to
what
what
problem
you're
trying
to
solve,
because
there's
a
couple
way
because
there's
another
problem
that
helm
charts
are
in
different
repos,
so
you
have
a
cross
repo
link.
That's
what
pr27
was
about
way
back
when
so
I
when
I'm
because
I'm
look
it's
a
it's
a
mind,
wrap
to
think
about
both
ways:
an
image
if
an
image
is
pointing
to
its
home
chart.
Yes,
you
could
actually
do
that
conceptually,
but
the
problem
is,
you
have
lots
of
helm,
charts
that
point
to
the
same
images.
F
D
F
To
blobs
well
so,
there's
a
so
that's
where
I'm
kind
of
getting
into
what
do
we
want
to
solve,
because
the
challenge
with
the
helm
chart
pointing
to
a
collection
of
images
is
a
helm
chart
would
be,
let's
just
say,
the
helm
chart
is
in
one
of
those
repos,
but
if
a
home
chart
is
deploying
one
image,
that's
not
very
interesting.
It's
when
the
helm
chart
is
deploying
two
or
three
images,
and
those
two
or
three
images
are
not
in
the
same
repo
right,
cnap
kind
of
went
through
some
of
this
stuff.
F
So
you
have
the
wordpress.
So
you
have
a
wordpress
container
image.
The
work
the
wordpress
helm
chart
the
wordpress
container,
which
actually
owns
the
code
for
running
wordpress,
and
then
you
have
is
it?
What's
it
two
other
containers,
there's
my
sql.
I
thought
there
was
something
else
so
there's
at
least
two
images
now
the
helm
chart
is
pointing
to
so
you
have
three
artifacts
the
helm,
chart
the
wordpress
container
image
and
then
the
mysql
database.
F
As
soon
as
you
start
talking
about
I'm
trying
to
point
across
repos
you
kind
of
get
into
an
interesting
world
of,
is
that
the
way
somebody
promoted
it
from
one
registry
to
another.
So
I
I
love
the
idea
of
supporting
helm
charts.
I
think
there's
a
couple
of
other
challenges
there
around
some
rename
and
there's
some
other
work.
I'm
trying
not
to
you
know,
get
too
conflated
here,
but
yeah.
I
I
don't
mean
to
focus
on
helm
like
that
itself,
but
just
like
the
idea
of
a
full-blown
application
containing
multiple
images,
so
whatever
whatever
that
means,
I
guess
well,
I,
while
I
have
my
mic
on
but.
F
I
G
Think
I'll
probably
reiterate
what
I
said
in
the
first
part,
which
is
this.
According
to
this
proposal,
we
expected
it
to
be
the
ionotype,
but
the
other
proposals
keep
it
string
form
free.
So,
as
a
reference
type
working
group,
we
should
decide
how
we
want
to
go.
I'm
I'm
open
to
both
ways.
I
don't
think
I
have
a
strong
opinion
either,
but
it
gives
some
structure
if
you
tell
them.
This
is
how
it
should
be
instead
of
free
from
annotation,
then
might
as
well
move
to
an
annotation.
F
The
problem
this
actually
came
back
from
when
the
oci
artifact
stuff
was
all
about.
It's
like
how
do
you
get
a
unique
identity
who
owns
signature
so
by
deferring
it
instead
of
oci
becoming
the
gatekeeper
of
who
owns
the
dot
word
file
extension,
for
instance,
that
somebody
else
can
squat
on
it
was
let's
defer
to
ayanna,
there's
a
place
there
that
you
can
register.
F
F
B
F
So
they
created
in
this
is
a
perfect
example
of
by
actually
implementing
the
specs
and
you
know
getting
use
cases
and
validating
those
over
time.
That's
this
is
how
some
of
these
things
surfaced
up.
So
they
created
was.
If
you
have
a
bunch
of
scan
results
and
there
might
be
a
hundred
of
them
or
every
couple
of
days
you
had
another
scan.
F
How
do
you
get
the
latest
version
and
by
the
way,
you're
probably
promoting
these
across
registries?
So
when
it
gets
pushed
to
a
registry?
You
can't
use
the
registry
date
because
the
registry
doesn't
know
if
it
was
the
first
time
it
was
pushed
or
not,
and
you
don't
want
to
put
limitations
on
the
order
of
which
things
get
pushed
between
registries.
So
the
whole
idea
is
the
artifact
owner
creates
it.
They
set
that
date
and
it's
a
knowledge.
It's
acknowledged
through
the
life
of
that
thing.
Moving
around,
I
forgot
it
was
actually
in
the
config.
D
D
E
F
You're,
I
think
we're
conflating
blobs
with
artifacts,
so
each
scan
is
its
own
artifact.
You
don't
have
multiple
scans
in
one
manifest,
because
the
whole
idea
is
on
monday.
I
do
a
scan.
I
push
that
on
wednesday.
I
do
a
scan.
I
push
that
thursday
blah
blah
blah
blah
blah
and
there's
no
there's,
never
any
aggregation
of
all
those
from
a
document.
They're
all
individual
artifacts,
as
somebody
promotes
it
from
registry
one
to
registry
two.
F
D
That
was
something
that
was
very
different
in
nisha's
proposal
versus
all
the
rest
of
ours,
which
was
that
I
think
her
proposal
was
looking
at
taking
you
if
you
want
to
update
and
add
a
new
scanners
or
something
like
that,
her
proposal
was
to
modify
that
existing
manifestnet
more
blobs.
That
list-
and
I
don't
think
anybody
else-
has
that
in
theirs
and
I
think,
there's
a
value
to
having
that
artifactory
push-up
being
immutable
once
you
push
it
up,
you're
not
changing
you're,
not
modifying
it.
F
One
of
the
things
that
makes
registry
scale
so
well
right.
You
can
globally
distribute
the
thing
with
multiple
replicas.
You
get
eventual
consistency,
because
the
only
thing
that
ever
gets
updated
is
a
tag,
and
if
people
follow
a
best
practice
that
tags
are
unique,
then
you
literally
have
something
you
can
push
in
multiple
regions.
They
get
they
all
merge
together.
You
never
have
any
conflict
across
a
manifest
that
might
get
updated
in
different
regions
like
keep
all
the
documents
separate
and
the
index
that
gets
managed
for
the
referrals.
F
Api
is
an
in-memory
thing,
as
artifacts
are
pushed
that
have
a
subject
property.
The
registry
sees
that
subject.
Property
goes
oh
you're,
pointing
at
another
thing.
Let
me
keep
that.
The
registry
manufactures
an
index,
not
an
oci
index,
just
a
collection
of
information,
and
then,
when
you
ask
referrers
api,
it
says
hey.
What
do
I
currently
have
and
there's
never
any
user
documents
that
change.
D
Minutes
left
any
any
last
thoughts
on
this
one
or
otherwise.
I
don't
see
the
other
hand.
So
I
was
gonna.
B
B
Can
we
remove
the
requirement
for
subject
digest
to
exist
from
json
and
then
add
more
annotations
to
the
config
example
from
brandon?
Are
they
the
only
three
amendments
that
we
want
to
make
to
the
proposal?
B
D
Next
item
so
mine,
I
don't
have
any
screen
share
anything
like
that,
but
I
was
going
to
suggest
maybe
making
a
proposal
e,
which
was
kind
of
taking
a
combination
of
what
we've
done
with
a
b
and
d
today
to
basically
create
a
new
media
type.
Probably
with
those
suggestions,
you
were
just
talking
about
lockheed
kind
of
changing
a
few
little
details
there,
but
probably
have
a
new
media
type,
add
a
reference
api
to
query
some
of
this
stuff
and
then
also
adding
the
refers
kind
of
data
in
there
and
I've.
D
I've
got
all
this
kind
of
jot
down
I'll,
throw
it
in
notes.
If
people
are
worried
that
you'll
miss
some
details
here,
but
basically
taking
all
the
best
of
each
of
those
things
having
tags
that
you
can
look
up
later
on
and
giving
people
a
way
that
they
can
call
this
stuff.
And
it's
yeah.
I
like
the
idea
frankenstein
proposal.
B
I
think
that's
a
good
approach.
Brandon,
I
I'd
I'd,
be
plus
one
for
that.
If
you'd
like
to
take
the
pen
and
then
present
it,
and
then
we
can
all
talk
over
it,
because
it's
kind
of
looking
like
forwards
compatibility
and
backwards
from
both
angles,
the
same
set
of
proposals
and
if
you're
willing
to
take
the
pen,
it
looks
like
everybody's
plus,
12,
plus
123,
and
I'm
going
to
call
it
the
avengers
proposal.
It's
the
the
the
proposal
is
greater
than
the
sum
of
the
parts
right.
B
Does
that
sound
okay?
So
if
you
want
to
take
the
pen
to
that
yeah
anything
else
before
we
finish
up
otherwise
thanks,
sergey
and
steve,
and
appreciate
the
engagement
and
all
the
proposals
so
far,
I
think
it's
been
great
to
talk
through
all
these
things.