►
From YouTube: [OCI-WG] Reference Types - 2022-05-10
A
A
D
C
Okay,
this
is
the
oci
reference
type
working
group,
hello.
Everyone
welcome
very
happy
to
see
everyone
here.
Just
this
meeting
is
recorded.
C
Please
be
civil
and
nice
to
each
other,
and
with
that,
let's
look
at
the
agenda
items.
First
up
is
the
pull
request
for
proposal
e
changes.
C
And
the
the
object
of
this
agenda
item
is
to
merging
changes
to
proposal
e
that
we
would.
This
group
would
be
willing
to
take
to
the
spec
maintainers
yeah.
C
Okay,
I
can
share
my
screen
if
y'all
want
to
take
a
look
at
the
the
pull
request
like,
maybe
maybe
that
would
help
sure.
C
I
wonder
if
that
so
I've
been
having
that
problem
with
my
linux
client,
and
I
wonder,
if
that's
you
know
something
to
do
with
where
we've
installed
the
linux
client
from.
I
think
I
remember
that
I
installed
it
from
the
snap
store
anyway,
digression
josh
go
ahead.
E
You're
muted
question:
you
did
yeah
thanks.
I
looked
at
this
yesterday,
so
I
just
want
to
confirm-
and
I
think
this
was
on
the
thursday
call.
We
talked
about
this-
the
we
will
be
using
the
extensions
api.
B
I
think
that's
the
that's,
possibly
still
a
topic
for
discussion.
I
don't
know
if
we
settled
on
it,
but
I
think
a
possible
compromise
is
to
prototype
it
using
the
extensions
api
and
you
know
get
a
feel
for
how
everything
looks
and
then,
when
we
have
an
extension,
it's
a
fairly
small
depth
to
just
say
this
is
you
know,
map
this
url
to
this
url?
Everything
else
works
the
same,
but
I
don't
know
if
you
know
I
think
sanjay
was
the
most
outspoken
person
in
favor
of
the
extension.
D
We
did
bring
it
up
in
the
last
oci
call
to
kind
of
ask:
where
should
we
go,
and
I
think
mike
also
kind
of
commented,
mike
brown
kind
of
commented
that
let's
prototype
it
in
this
place,
see
if
it
goes
and
then
make
it
into
a
regular
path?
That's
needed.
So
there's
no
there's,
no
strong
objection
as
to
moving
it
to
a
regular
path,
but
getting
some
validation
on
the
extension
quickly
might
be.
The
the
least
friction
sounds
good
sounds
good.
E
Yeah,
I
I'm
I'm
re-reading
the
pr
and
it
has
I
just
put
it
in
the
chat,
but
it
says
working
group
testing.
Api
extensions
proposed
api
for
distribution,
spec,
no
extension,
so
I'm
I'm
totally
fine
with
that.
I
just
I
just
want
to
be
on
the
same
page
for
the
prototyping
efforts.
C
I'll
call
myself
with
my
hand,
raised
so
sajay:
do
you
think
that
having
another
registry
provider
join,
you
in
you
know
implementing
the
extensions
to
to
show
viability?
A
D
They
have
gone
ahead
and
implemented
a
set
of
extensions
like
storing
scan
results
and
different
kinds
of
operations.
I
think
there
are
like
four
extensions
that
they
already
implemented
specifically
for
zot.
These
are
there's.
It
gives
them
an
easier
way,
so
that
parts
don't
stomp
over
oci
is
special,
because
I
think,
as
those
a
group
we
can
sit
under
any
place
and
just
rep
the
spec,
but
it's
just
being
conscious
of
other
people
who
have
capabilities
that
they've
built
over
distribution
and
being
mindful
of
not
kind
of
stomping
over
their
path.
D
That
is
the
motivation,
so
the
other
thing
is
that
the
oci
discover
is
actually
implemented
as
an
oc
extension.
So
it's
not
that
oci
does
not
have
extensions.
It's
more
like
this
is
the
playground.
This
is
the
experimental
way.
Let's
get
it
in
there,
let's
test
it
out
there
without
actually
having
to
write
a
full
distribution
spec
and
then,
if
we
like
it,
we
can
immediately
kind
of
ratify
distribution
and
say
that
let's
make
it,
let's
move
the
path
down.
I
it's
it's
just
a
url
change.
D
The
advantage
is
that
we
can
route
it
directly
in
different.
I
mean
if
you
have
different
things
like
how
to
route
your
protocols,
then
it
makes
it
easier
to
kind
of
like
have
everything
under
this
prefix
move
to
this
specific
thing.
So
both
proposals
kind
of
like
say
that
either
we
move
it
under
references
or
under
extension,.
D
The
feedback
like
if,
if,
if
the
group
says
that
let's
move
it
directly
on
a
distribution,
let's
do
that,
like
I
said
whatever
makes
it
easy
to
kind
of
make
it
into
distribution
of
what
I'm
hoping
we
can
get
them.
There's
no
strong
opinion
either
way.
B
Was
gonna
say
I
guess
I
guess
I'm
worried
that
if
we
only
propose
an
oci
extension
that
distribution
spec
will
just
say
you
know
not,
we
don't
care,
do
whatever
you
want,
it's
an
extension
and
it
it
will
make
our
work
product
a
little
less
real,
as
opposed
to
being
like
you
know
we
can
demonstrate
here
is
an
extension
here.
You
know
go
play
with
it.
You
can
use
it
right
now.
B
D
Yes,
I
think
that's
what
the
spec
calls
out
right
like
we
prototype
it
as
an
extension,
we
kind
of
get
an
rc1
alpha
something
and
then
we
can
immediately
say
this
is
all
good.
We
like
the
spec
parties
who
are
using
it,
have
a
good
sense
of
it
and
if
everybody
says,
let's
move
it
over,
it
makes
the
the
problem
is.
My
hope
is
that
we
don't
have
to
move
it
twice.
Yeah
right,
I
I
want
to
do
one
url
change.
D
We
experiment
we
get
that
and
then
we
move
it
over
to
everybody
agrees
from
the
maintainers
group
saying
that
this
is
the
name
that
we
want,
because
reference
references,
all
those
kind
of
discussions
will
happen
and
we
make
the
move
one
time.
That's
that's
what
I
thousand
percent
yeah
thousand
percent.
C
I
agree.
Okay,
so
I've
raised
my
hand
up.
I
I'm
wondering
like
how
this
can
be,
how
the
I,
I
suppose,
for
lack
of
a
better
term.
The
popularity
of
a
particular
extension
can
be
demonstrated
to
to
the
distribution
spec
maintainers.
So
how
do
we
say,
like
you
know,
okay,
this
company,
this
organization
has
adopted
this
list
of
ex
these
set
of
organizations
have
adopted
these
set
of
extensions.
C
Therefore,
we
think
that
this
is
needed
in
the
spec.
B
B
I
think
it's
more
like
it
will
sort
of
be
a
speculative
spec
change
like
we
think
this
is
a
good
addition
to
the
spec,
even
though
perhaps
nobody
implements
it
or
very
few
people
and
then
I'm
sure
we'll
have
a
hashing
of
back
and
forth
of
ideas
and
rewordings
and
things
and
then
at
the
end
of
it,
then
we
use
just
its
inclusion
and
distribution
spec
as
a
lever
to
get
registries
to
implement
it
to
get
to
get
all
the
registries
to
implement
it.
B
If
some
support
it
before
we
take
it
to
distribution
spec
as
an
extension,
then
great-
and
I
think
that's
that's
some
signal,
but
I
don't
think
the
goal
is
to
get
broad
adoption
and
then
take
it
to
distribution
spec,
but
rather
some
adoption
and
a
prototype.
You
can
use
to
distribution
spec
and
then
from
there
get
everybody
else.
Does
anyone.
C
B
Me
know
if
people
disagree
with
that
assessment
or
plan
or
whatever.
C
I
I
mean
I'm
I'm
okay
with,
however,
it
gets
adopted.
The
the
trouble
here
I
feel
is
that
the
distribution
spec
will
not
adopt
it,
because
it's
in
extensions
and
extensions
does
not
does
not
overlap
with
all
their
operations
right.
So.
B
F
D
Sure
sanjay
has
his
hand
up
first,
I
cannot
do
anything
about
docker
up.
That's
that's
their
operation,
their
their
company,
as
as
we
want
to
call
it
right,
the
the
thing
I
do
want
to
call
out
is
my
hope
is
that
the
next
working
group
comes
along.
D
We
set
a
path
so
that
they
don't
have
to
battle
of
how
they
can
make
a
change
to
the
oci
spec
going
forward.
We
we
set
a
trend
as
to
okay.
You
experiment
here,
others
can
adopt
it
quickly
and
then
we
move
on,
and
this
is
a
proposal
path.
That
is
what
I'm
hoping
for
so
every
time,
if
we
propose
like
a
spec
chain,
distributed
change
directly
from
the
working
group,
there's
no
path
to
validate
whether
this
is
usable
or
not,
for
example,
the
spec
right
now
in
the
current
shape.
D
We
have
no
filtering,
and
that's
one
thing
that
I
put
in
the
notes.
We
probably
want
to
at
least
discuss
what
is
the
base
minimum
viable
use
case
of
I
have
100
scan
results
or
100
signatures.
How
do
I
at
least
be
able
to
distinguish
without
pulling
down
the
entire
set?
Should
we
talk
about
that,
and
maybe
the
proposal
will
be
that
this
is
fine
and
we
take
it
forward
and
at
the
time
of
saying
that
the
working
group
is
happy,
there
are
implementations,
you
want
to
move
it
forward
into
distribution.
D
We
can
move
it
directly
under
slash
references
or
something
like
that,
and
we
agree
as
a
group
to
do
that.
The
same
process
can
be
taken
to
the
next
one,
because
I
think
there
was
a
lot
of
interest
on
making
search
happen
right.
Can
I
find
images
with
certain
annotations
and
all
these
things,
and
how
can
we
kind
of
like
or
have
these
things
going
forward,
just
want
to
set
that
machine
moving?
Also,
rather
than
just
making
this
the
final
outcome
of
the
the
workflow
is
important.
B
Yeah,
I
agree.
I
think
our
our
goal
is
to
make
a
change
and
to
show
future
us
how
to
make
a
change
so
that
this
is
not
such
a
laborious
time,
time,
sensitive
process,
time,
intensive
process
to
the
point
about
docker,
supporting
it
or
anyone
really
any
registry
supporting.
We
can't
make
anybody
support
it,
and
I
will
say
I
think
there
is
a
risk
that
you
know,
though
we
are
a
broad
set
of
folks
and
are
making
a
very
deliberative
change.
B
B
I
think
it
would
probably
cause
a
lot
of
difficulty
for
us
personally,
not
because
whatever
they
build
would
be
bad
and
we
wouldn't
just
stop
like
follow
it
anyway,
but
it
would
be
very
well
I'll
say
annoying
to
me
if,
after
all
of
this
work,
docker
just
comes
up
with
their
own
thing
and
because
of
the
realities
of
the
world,
we
all
just
implement
it
anyway,
oh
hey,
lockheed's!
Here
I
will.
I
will
see
my
time
I
think
nisha's
next.
C
So
the
reason
why
I
ask
that
question
is
whether
to
figure
out
whether
the
reason
for
having
so
much
of
trouble,
turning
this
into
a
spec
change-
and
maybe
maybe
I
am
misinterpreting
this-
whether
we
are
going
in
the
direction
of
we'll
we'll
just
implement
these
things
as
extensions
and
if
and
whatever
happens
in
distribution
spec
happens
in
distribution
spec.
C
These
will
be
completely
separated
from
that.
Is
that
the
direction
we're
going
or
is
the
direction
we
will
implement
these
things
in
as
extensions
for
now
and
then
at
a
later
date
we
will
propose,
we
will
propose
the
cha.
The
changes
aspect
changes
so
it
from
the
nodding.
It
seems
like
we
want.
The
latter.
B
Yeah,
my
interpretation
is
definitely
the
latter
and
in
fact
I
would
propose
that
we
not
make
two
sets
of
proposals
to
distribution
spec.
I
think
we
we
in
this
group
decide.
This
is
what
we
think.
A
good
set
of
you
know.
Set
of
functionality
is
show
it
working
as
an
oci
extension,
so
that
anybody
who
wants
to
can
go
and
poke,
and
you
know
see
it
in
real
life
and
then
take
that
to
distribution.
Maintainers
and
say
here
is
a
working
version
as
an
oci
extension.
B
C
B
I
don't
think
I
don't
think
each
organization
like
makes
a
change
to
the
spec
themselves.
I
think
we
we
agree
about
what
the
shape
of
this
change
is,
and
somebody
implements
it
somewhere
on
zot
or
distribution
or
their
own
hacked
registry
or
whatever,
as
an
oc
with
oci
extension
pads,
and
then
we
make
one
unified
distribution,
spec
change
with
with
all
of
our
you
know,
with
the
united
front,
as
this
working
group
agrees,
we
like
this
change.
C
So
this
is
this
is
where
I'm
having
like
misgivings
about
you
know,
leaving
it
up
to
implementers
to
do
whatever
changes
they
want,
because
well,
so
so
here
it
so
here
we
have
like
several
people
who
are
representing
different
companies.
They
all
have
customers,
the
customers
have
use
cases
we
have
listed.
All
the
use
cases
is
our
each
of
us
going
to
go
back
to
our
companies
and
say
well.
This
is
the
decision
that
this
working
group
has
made.
B
C
Okay,
so
implementing
the
thing
that
we
all
agree
on,
where
is
that
reference.
B
C
Right
but,
but
is
that
like
going
to
be
on
like,
for
example,
oci
playground.
D
No
it
currently,
the
path
is
under
underscore
oca.
The
extension
is
an
oc
extension.
What
we
are
saying
is
that
this
will
be
like
referred
as
as
something
that
the
oci
working
group
is
proposing.
D
D
B
Believe
josh
was
making
some
prototype
changes
in
oci
playground
to.
I
forget
whether
it
was
or
distribution,
but
that
is
not
any
sort
of
official
location.
That
is
a
place
where
someone
can
do
this.
You
can
go
do
that
somewhere
else.
If
you
want
to
so
long
as
at
the
end
of
this,
I
think
we
have.
We,
as
a
group
have
one
thing
we
say
this
is
a
a
demonstration
of
the
thing
we
are
proposing
to
distribution
spec
as
a
single
group.
C
F
C
I
I
feel,
like
you
know,
having
a
number
of
contributors
to
one
repo
would
demonstrate
that
you
know:
there's
a
bunch
of
code,
that's
shared
by
many
different
organizations
and
downstream
it
would
make
us
easier.
It
would
make
it
easier
to
put
those
changes
up
to
distribution.
C
I
I'm
sorry
it's
like
for
for
the
spec,
the
distribution
spec,
not
distribution
itself,
yes,
yeah.
E
Oci
playground,
nisha,
I
think,
is
what
that
was
my
kind
of
proposal
as
the
home
for
these
types
of
group
prs
or
group
changes.
So,
like
you
know,
we
could
do
the
distribution
thing
in
anisha
for
or
maybe
we
could
have.
The
distribution.
Spec
maintainers
make
us
a
branch
there,
but
oci
playground
is
just
something
that
is
easy
to
type
in
the
in
the
browser.
So.
C
G
Yeah,
I
was
going
to
say
whatever
the
name.
It
would
be
good
for
us
to
have
a
reference
reference
implementation
of
the
extension
that
you
know
we
could
all
collaborate
on
in
a
shared
space
and
that
can
be,
you
know,
implemented
via
the
extension
model
under
distribution
or
if
somebody
has
they're
not
using
distribution,
they
might
want
to
look
at
the
code
for
the
implementation,
but
we
would
do
that
post
proposal.
I
don't
know
that
we
need
to
rock
up
with
the
actual
reference
implementation.
I
know.
E
A
E
B
C
B
I
just
wanted
to
sort
of
call
time
on
this
discussion
because
we
have
other
stuff
about
the
filtering
and
artifact
type
and
other
stuff,
but
I
don't
mean
to
cut
anybody
off
if
they
had
things
to
say.
I
just
think
we've
got
a
we've
got
an
agenda
to
think
of.
C
D
So,
to
kind
of
like
maybe
time
is
important,
so
let's
do
that.
I
also
shared
a
pr
where,
over
last
week,
we
created
proposal
is
like
a
sample
a
way
to
just
like
implement
it.
On
top
of
distribution,
create
an
extension
use
like
raw
http
just
to
get
it
working.
D
We
have
a
sample
repo
with
like
the
spec,
that
is
in
proposal
e
converted
to
a
set
of
golan
files,
also,
so
that
we
can
reference
and
play
with
it
just
to
get
an
idea
of
how
this
feels
over
over
time.
That's
something
that
we
can
collect
it
if
we
want
to
move
on
to
the
the
second
part
of
the
discussion
about
filtering,
the
question
primarily
was
right.
Now
there
is
no
filtering
in
proposal
and
I
think
we
should
merge.
D
What
is
what
is
there
like
as
a
pr
because
it
just
adds
to
what
it
is.
It
doesn't
take
away
anything
and
doesn't
change
the
course
of
things.
Should
we
have
a
basic,
viable
implementation
where
you
can
filter
something,
and
that
is
one
of
the
reasons
why,
in
proper
we
submitted
at
least
artifact
type,
because
adding
a
full-blown
annotation
filtering
is
definitely
challenging
for
anybody
to
implement
at
this
point
in
time.
C
I
think
I
have
my
legacy
hand
up.
That's
fine,
and-
and
this
is
this
is
another
reason
why
I
asked
like
that
original
question.
If,
if
there
was
another
like
implementer
registry
implementer
that
came
in
and
tried
to
do
this,
would
that
strengthen
the
proposal.
C
Yeah,
so
I'm
asking
because
I
have
to
justify
my
time
spent
here.
E
C
Okay,
I
think
sajay
is
sanjay,
is
frozen.
Jason.
B
Yeah
I
wanted
to
go
to
sanjay's
question
about
massage
point
about
artifact
type
filtering.
B
B
Artifact
type
filtering,
wouldn't
really
help
there
right,
because
if
you
have
a
thousand
things
of
type
vulnerability
scan,
then
filtering
out
the
you
know
the
one
or
two
signatures
of
the
one
or
two
s
bombs
isn't
really
gonna.
Save
you
a
lot.
I
wonder
if
the
solution
is
to
recommend
people
not
poop
something
into
the
registry
every
day,
especially
if
it's
like
more
or
less
the
same
information
as
yesterday
or
presumably
you
know,
today's
vulnerability
scan
is
probably
the
same
as
yesterday's.
B
C
H
I
guess
I
think
that
that's
one
option
of
just
having
people
either
not
do
that
or
whenever
they
push
a
new
thing,
delete
the
old
thing.
You
know
what
one
thing
we
talked
about
is
is
we
could
use
the
push
time
or
the
created
that
time
as
a
sort
field?
And
so,
if
you
have
you
know,
if
you
have
sorting-
and
you
have
this
filtering,
you
know
a
single
dimension
of
filtering
you.
You
can
actually,
I
think,
accomplish
most
of
the
use
cases
we're
talking
about
without
having
to
go
full-on.
H
B
Yeah,
nothing
in
distribution,
like
does
anything
with
push
time
today
or
nothing
in
distribution
spec.
You
know,
I
don't
think
the
push
time
is
even
mentioned
as
a
concept
in
distributions
back
today,
so
we
would
have
to
sort
of
invent
that
and
specify
it
not
that
that
means
we
shouldn't,
but
just
like
that
is,
I
do
think.
That's
a
a
good
scoping
down
of
you
know,
indexing
all
annotations
or
indexing
most
some
annotations
yeah.
C
H
B
I
believe
that
I'm
looking
at
proposal
e
right
now,
I
think
the
latest
draft-
and
it
says
an
artifact-
may
have
an
annotation
added
with
a
timestamp
version
or
similar
value.
These
annotations
could
be
queried,
etc,
but
not
that
you
should
or
must
or
have
you
know,
have
to
have
the
timestamp
field,
it's
sort
of
the
same
with
an
image
today.
You
can
also
do
this
with
an
image
today
you
can
put
that
in
there
and
then
filter
on
your
way
on
your
way
out.
C
I
I
was
just
thinking
in
addition
to
the
time
stamp.
There
was
the
thought
I've
seen
a
few
times
of
how
do
you
filter
by
who
did
the
signing.
So
if
you
have
multiple
signers
out
there
and
you
want
to
find
year,
one
signature,
I'm
just
imagining,
there's
many
more
and
more
filter
scenarios
that
we
didn't
capture
in
our
use
cases
here
that
people
are
going
to
want
to
ask
later
on.
B
Yeah
filtering
definitely
gets
complex.
I
think
that's
why
we
need
to
shy
away
from
it
as
much
as
possible.
In
particular,
the
signature
case
has
a
lot
of
corners
because
currently
for
cosine
at
least
you'd
have
to
like
deeply
inspect
that
image
to
even
get
any
kind
of
identity
out
of
it,
and
there
may
not
be
an
identity
like
you
expect
there
to
be,
it
might
not
be.
You
know,
brandon
mitchell.com,
it
might
be
this
github
repo
or
this
anybody
holds,
might.
B
Yeah,
so
I
think
I
think
that's
a
you
know,
that's
a
very
good
example
of
a
super
complex
maze.
I'd
like
to
avoid
completely,
I
think
we,
I
think
there
is
a
use
case
for
it
like
show
me
whether
brandon
signed
this,
but
I
think
that
gets
very
complex
and
implementation.
Specific.
B
B
C
I
guess
in
the
registry
domain,
so
you,
for
example,
you
would
fetch
a
manifest
and
then
that
manifest
can
go
to
some
other.
Some
other
thing
that
will
do
the
filtering
for
you.
B
It
kind
of
at
least
you
know
for
the
immediate
future
that
that
clients
would
have
to
go
through
every
page
of
the
results
and
hopefully
not
also
have
to
go
fetch
another
manifest
to
do
any
more
filtering,
but
perhaps
on
from
enough
information
in
the
descriptor
to
not
have
to
go
through
lucky.
I
don't
know
if
you
have
an
answer
to
this
as
well.
G
Actually,
I
do
have
the
answer.
No,
I'm
kidding
thank
you
for
asking
31
the
answer.
It's
actually
42.
sanjay.
Can
you
just
restate
the
question
I
just
want
to
make
sure
I
get
the
spirit
of
it
then
respond.
D
So
the
question
was:
we've
dropped
all
of
the
filtering
requirements.
Proposally.
D
Should
we
have
a
minimal,
viable
experience
where,
if
we
have
two
different
type
of
artifacts,
we
can
at
least
get
that
set
somehow,
because
we
would
attach
signatures
s-bombs,
vulnerability,
scans
and
different
things,
and
or
should
we
just
state
that
we'll
pull
down
everything
from
the
registry
for
a
given
image
and
then
filter
it
on
the
client
either
way
is
okay.
D
The
only
challenge
is
that
adding
a
full-blown
annotation
filtering
is
just
an
expensive
implementation
problem,
so
I
don't
want
to
go
there
right
now,
but
hopefully
not
have
to,
but
at
least
should
we
propose.
We
start
with
something
simple
and
then
we
add
on
more
keep
going-
or
we
kind
of
like
say
cut
it
off
altogether,
so
that
we
can
agree
on
what
is
the
what's
the
path
forward.
G
Thanks
thanks
rj
just
to
respond
to
that
is:
what
do
you
think
the
value
of
having
it
there
is
that
everybody
follow
it
or
that
people
can
kind
of?
If
there's
an
mvp
in
there,
that
people
can
visualize
how
to
create
filtering
from
this?
I'm
just
wondering
what
is
the
purpose
of
having
it
codified
in
the
proposal?
D
Okay,
so
I
think
the
changes
to
the
artifact
spec
or
emit
spec
is
the
toughest
one,
because
it
it's
about
persistent
documents.
We
can
change
the
reference
api.
However,
we
want
to
right
because
it's
a
get
path.
It's
not
gonna
affect
it,
but
as
soon
as
the
moment,
we
kind
of
like
try
to
ask
customers.
Hey
you
have
to
put
yet
another
field,
it
becomes
change
of
the
persistent
document.
It
changes
the
digest
of
the
manifest
and
those
kind
things
so
qualifying
that
requirement.
D
Upfront
enables
us
to
at
least
use
those
things
later
on,
but
it
doesn't
solve
all
the
cases.
So
it's
about
whether
we
agree
that
okay,
this
is
the
minimum
viable
experience
that
we
have
where
we
can
store
s-bombs
and
signatures
and
any
other
cool
stuff
related
with
the
image,
and
then
we
can
query
them
without
polluting
the
whole
pool
of
I
want
to
find
signatures,
but
you're
also
giving
me
the
standard
of
scan
results
or
vulnerability
results
or
whatever
it
is
right
so
and
because
sorting
is
also
not
there.
I
On
the
descriptor
list,
it's
all
been
pulled
up,
and
so
the
client's
got
everything
they
need,
including
the
artifact
type,
including
all
the
other
timestamps
key
fields,
any
other
details
that
are
in
there.
There
are
push-up
annotations
they're
all
there
at
the
clients
how
to
do
that
without
any
other
request.
D
That
sounds
good.
I
think
that
that
means
that
we
we
at
least
codify
that
implementation
of
the
reference
api
should
return
all
the
manif
all
the
annotations
in
the
manifest
level
right.
I
D
D
But
if
that's
what
the
spec
says
and
that's
what's
mixes
and
I'll-
probably
leave
it
to
john
and
michael
to
describe.
Is
that
feasible
from
a
cost
perspective?
Or
if
it's
not?
If
it's
not
a
problem,
then
we
kind
of
agree:
it's
okay
and
let's,
let's
make
that
option.
B
I
think
that's
also
something
we
can.
We
can
suss
out
as
we
prototype
and
implement
the
extension
right
like
once
once
we
have
it
working
with
with
hoisting
the
annotations.
We
can
do
not
exactly
a
load
test,
it's
not
a
production
service,
but
like
what
happens,
if
I
put
a
thousand
vulnerability
scans,
what
happens?
C
So
again,
we're
almost
coming
to
like
15
minutes
to
the
top
of
the
owl.
Do
we
have
consensus
on
whether
to
whether
to
keep
filtering
or
drop
it
all
together
from
the
proposal.
B
I
think
I
I
interpreted
this
as
deciding
not
to
implement
filtering
in
the
initial
proposal
we
send
to
distribution
spec
and
that,
if
you
wanted
to
filter
you
can
you
should
be
able
to
do
so,
at
least
on
manifest
annotations
that
get
hoisted
into
the
preferrers
api
response.
So
you
don't
have
to
hold
a
thousand
manifests.
That's.
C
Yeah
yeah,
okay!
So
then
we'll
move
on
to
the
next
one,
which
is
to
is:
should
we
return
referrers
or
leave
it
up
to
cloud
providers
to
decide
the
impact
of
introducing
it.
D
It
was
continuing
last
week's
question,
which
is
we've
added.
D
And
what
what
was
the
consensus
was
more
like
the
question
that
I
had
it's
like
did
we
agree
on
saying
that
we
would
support
it
later
at
some
point
in
time,
or
do
we
off
the
bat
go
say
or
do
cloud
providers
have
an
option
of
saying,
hey,
we'll
implement
it?
We
might
or
might
not
implement
it.
What
what's
the
what's
the
ask
here?
D
I
think
this
is
also
important
for
both
for
me
and
michael
brown,
to
kind
of
at
least
understand
in
if
we
bring
a
new
image
manifest,
what
should
we
do
with
it,
and
if
we
have
old
image
manifest?
What
should
we?
How
should
we
kind
of
reconcile
it
at
some
point
in
time
we
could
do
like
an
alternate
put
like
ask
the
client
to
put
it
again
so
that
actually
triggers
the
workflow.
D
But
that's
that's
a
tougher
ask
because
you
have
to
get
the
manifest
correctly
and
put
it
back
and
refresh
it
somehow
so,
just
to
kind
of
like
bring
everybody
to
the
same
page.
Did.
I
My
pull
request
give
you
a
little
bit
happier
thoughts
on
that
one
from
what
I
was
suggesting,
which
was
that
you
only
have
to
scan
the
stuff
that
has
a
digest
tag
on
it.
You
don't
have
to
scan
your
entire
registry.
You
only
have
to
scan
those
things
that
have
the
digest
tag
already
pushed.
I
I
H
I
B
We
talked
about
this
last
week
right
or
was
it
at
the
oci,
the
thursday
call,
I
don't
remember,
but
but
basically
I
don't
think
there
is
any
reason
you
have
to
do
any
kind
of
backfill.
If
you
want
to.
I
think
a
nice
thing
you
could
do
is
what
brandon's
saying
and
and
scan
for
register.
You
know
digest
tags
and
backfill
those,
but
I
think
it's
a
reasonable
expectation
as
a
user.
B
It's
a
reasonable
expectation
to
me
that
if
I
push
something
that
the
registry
didn't
understand
three
years
ago
that
they
don't
have
to
when
that
gains
meaning
next
week,
they
don't
have
to
go
back
and
make
that
meaningful.
For
me,
I
don't
agree
sure
I
think
I
think
the
more
important
thing
is
you
don't
have
to
do
a
full
backfill
of
every
manifest
in
the
entire
universe.
I
The
reason
I
push
for
the
partial
backfill
is
that
as
a
client,
if
you
query
the
registry
and
see
the
api,
you
shouldn't
then
also
still
go
back
and
do
the
tag
listing
you
should
be
doing
one
or
the
other
as
the
client,
and
so
once
the
registry
says
have
the
api
available
here,
then
you
shouldn't
have
to
go
back
and
look
for
those
tag.
Digest.
B
B
Perfect
see
you
you've
made
the
right
decision
for
yourself
but
yeah.
I
don't
know
that.
I
don't
know
that
the
working
group
has
to
come
up
with
any
official
guidance
for
cloud
provider
registries
or
any
registry
implementation
for
as
far
as
backfill
you
can
talk
to
brandon
and
get
you
know
he
can
tell
you
what
you
what
he
thinks
you
should
do,
but
that's
not,
I
think,
within
the
scope
of
the
working
group.
I
B
Yeah,
that's
that's
the
that
is
the
most
painful
possible
pain
point
which
is.
B
I
can
push
these
around
between
ecr
and
acr
just
fine
and
they
know
what
it
means
and
then,
in
a
year
gcr
I'll
pick
on
john
in
a
year,
gcr
picks
up
semantic
meaning
for
this
field,
and
the
experience
is
bad
because
I
have
been
able
to
push
them
between
these
two
just
fine
and
get
all
the
good
all
the
good
new
stuff
and
over
there
it
doesn't
or
it
you
know
they
have
to
do
a
that's
all
the
more
reason
to
upgrade
faster
right
so
that
your
backfill
window
is
shorter
and
shorter.
H
I
Yeah,
but
I
think
we're
leaving
it
as
it's
a
known
cost
of
the
registry,
because
you
can
look
at
how
many
digest
tags
are
sent
there,
so
you
know
how
much
you're
going
to
do
the
indexing.
That's
seen
on
your
registry
and
you're
not
forced
to
do
this
at
any
one
point
in
time.
You
can
pick
your
upgrade
window
whenever
you
think
makes
the
most
sense
for
your
registry.
I
B
Right
fallback
is
fine,
but
not
both
you
shouldn't
have
to
do
the
the
good
path
and
the
old
path.
I
think
that's
a
goal.
Yeah.
C
H
I
I
C
B
H
Agree
that
it's
an
anti-pattern,
I
don't
know
if
I
feel,
as
though
I
would
be
very
successful
in
introducing
that
limitation.
C
I
would
predict
that
if
the
annotations
get
like
really
large,
then
folks
would
stick
all
of
that
metadata
in
another
artifact
and
make
a
reference
to
that.
Instead,.
I
B
We
also
talked
in
that
discussion
about
the
four
megabyte,
manifest
limit
or
yeah
about
specific
limits
to
annotations
that
you
know,
I
think,
along
the
same
lines
in
the
in
the
language
of
implementations,
may
reject
annotation
values
over
1k
or
over
one
megabyte,
or
you
know
something
like
that.
B
I
think
if,
if
you're
worried
about
annotation
size
ballooning,
I
can
already
push
the
collected
works
of
shakespeare
in
an
annotation
in
an
image,
and
you
can't
stop
me
and
if
you
it
and
you
should
be
able
to
stop
me,
I'm
saying
like
that's
a
ludicrous
thing,
you
should
be
able
to
stop
me,
but
no
one
can
stop
jason.
No
one
can
stop
j
I'll,
just
chunk
it
into
two
or
three
different
annotations.
It's
fine.
G
G
B
G
It's
just
like
you
know,
using
annotations
in
general
to
do
heavy
lifting
and
not
putting
first-class
fields
and
specifications.
It's
it.
I've
just
seen
that
pattern.
We're
basically
going
to
relegate
a
lot
of
heavy
lifting
to
annotations
which
doesn't
give
us
early
validation,
doesn't
give
us
typing,
we've
got
and
people
will
shove
objects
in
their
json
objects.
You
know
I've
seen
it
all
the
time
json
you
will
become
a
manifest.
I
will.
G
F
C
C
And
there
is
three
more
minutes
and
jesse
just
put
his
hand
up.
I
would
like
to
give
him
an
opportunity
to.
G
I
G
I
Strict
field,
or
whatever
value
for
each
different
thing
you
want
to
filter
on,
and
so
you
have
to
make
an
artifact
type.
You
have
to
make
a
created
time.
You
have
to
create
each
individual
field
you
want
to
filter
on.
There
will
be
no
free
form
filters
for
users.
I.
G
H
Yeah-
and
I
think
my
big
concern
with
just
lifting
the
annotations
and
putting
it
into
the
responses
is
just
with.
Basically,
we
now
have
unbounded,
you
know,
response
items
and
and
sure
maybe
your
artifact
type
becomes
like
a
the
full
works
of
shakespeare,
but
I
think
that
typically
having
a
single
field
for
this,
and
not
just
lifting
all
of
the
artifact
or
sorry,
all
the
annotations
into
this
response
will
allow
us
to
provide
a
little
more.
I
C
So
we're
on
we're
out
of
time.
Do
we
want
to
continue
this
conversation
next
week
next
week,
this
bit
about
annotations
and
how
to
migrate
them
into
filtering
parts.
B
I
would
like
to
separate
the
con
the
conversation
about
field
versus
annotation.
From
the
conversation
about
filtering.
I
think
we
mostly
agreed
correct.
You
have
no
time
to
disagree
with
me.
We
mostly
agreed
that
filtering
is
out
of
scope,
but
the
annotation
versus
artifact
type
actual
field
is,
I
think,
a
discussion
worth
having
in
the
future.
C
Okay,
I'll.
B
C
Put
that
in
for
next
week
and
call
it
good.