►
From YouTube: [OCI-WG] Reference Types - 2022-04-12
A
B
B
A
A
B
F
F
C
E
F
F
Didn't
know
what
I
walked
into
there
on
that
one:
the
jellyfish
okay,
but
where's,
the
clownfish
reference.
Is
there
clowns
in
there
too?
Well.
B
A
F
G
C
B
B
Okay,
shall
we
shall
we
get
into
it?
So
you
you
add
that
josh
to
the
agenda
proposal,
I
think
we're
up
to
f
now.
B
Yeah
either
that
or
we
can
go
to
to
greek,
but
there's
less
less
letters
there
as
we
found
out
behind
our
head
symbols,
you've
got
to
start
adding
primes.
Okay.
Let
me
let
me
ice
cream
flavors,
exactly
endless
endless.
B
Too
josh,
so
just
let
me
know:
okay,
let's
kick
it
off
here,
hello
and
welcome
to
the
oci
working
group
for
reference
types
today
is
tuesday
april
12th
lovely
to
see
everybody.
Today
we
have
two
agenda
items:
I've
dropped
the
link
to
the
agenda
and
meeting
minutes
in
the
the
chat
there
please
go
ahead
and
add
your
name
to
the
attendees
list.
Thank
you
very
much
nisha
for
volunteering
to
be
our
notetaker,
really
appreciate
that
and
for
josh
dolitsky
to
be
backup,
notetaker
we'll
get
into
it.
First.
B
We
have
brandon
presenting
proposal
e
and
I
already
see
your
screen
brandon.
So
thanks
for
coming
for
bed
pass
it
to.
A
You
yeah,
it
takes
me
a
minute
to
get
all
the
chat
windows
up
and
everything
else,
so
I
figured
I'd
start
early
yeah,
so
this
is
kind
of
trying
to
pull
together.
Everything
we've
been
discussing
so
far
in
a
b
d,
and
there
there's
even
a
little
bit
of
c
in
there,
so
we
haven't
completely
lost
it
so
yeah
this
is
trying
to
pull
them
all
together.
I'm
gonna
probably
go
with
this
view.
I
think
it's
a
little
bit
easier
to
read.
A
So
this
is
the
cherry
pick
proposal,
and
so
I
am
adding
another
media
type
in
there.
That
was
one
of
the
things
that
came
out
of
a
was
we're.
Looking
at
saying,
we
probably
want
another
media
type,
because
image
spec
felt
a
little
too
constrained
for
certain
use
cases.
A
I
am
defining
a
reference
type
so
that
got
pulled
in
from
b
where
we're
saying,
let's
add
a
reference
type
to
existing
objects,
but
I
only
put
it
on
the
new
media
type
that
we
defined
and
the
image
manifest.
I
didn't
put
on
anything
else,
so
it
avoids
a
bunch
of
looping
concerns.
It's
not
going
to
go
on
blobs.
It's
not
going
to
go
on
arbitrary,
digest
or
arbitrary
descriptors
and
it's
not
going
to
go
on
the
index,
because
index
could
potentially
give
us
looping
issues
and,
let's
see,
defines
annotations
for
filtering.
A
So
I
know
that
we
are
looking
at
artifact
type,
making
that,
like
a
first
class
level
object
in
there
when
I
went
through
and
tried
to
figure
out
all
the
different
logic
in
this.
I
couldn't
come
up
with
a
solution
where
artifact
type
would
be
everything
I
wanted,
and
I
figured
if
I
can't
have
that
be
everything
then
I'm
gonna
have
to
support
both
filtering
of
artifacts
and
this
artifact
type
annotations
and
this
artifact
type,
and
if
I'm
gonna
have
to
do
both.
A
But
if
the
api
doesn't
exist,
I
fall
back
to
the
digest
tag,
syntax
that
we
were
talking
about
in
proposal
d,
so
that's
kind
of
where
we
pulled
all
all
three
of
those
together
into
different
things
here,
and
so,
let's
see,
the
idea
here
is
that
we're
gonna
have
an
upgrade
path,
and
so
registry
is
a
start
today
with
nothing
else,
no
api,
no
media
type
or
anything
else.
You
push
your
object
up
with
the
image
manifest.
A
That's
how
oci
defines
their
artifact
today
and
you
push
the
digest
tag
and
anywhere
else
that
can
query
that
can
query
the
digest
tag,
pull
it
down,
pull
the
artifact
and
we
now
have
references
without
doing
anything
else.
So
we've
got
this
as
of
today.
It
should
just
work.
If
we
do
this,
the
only
the
only
thing
holding
us
back
is
just
everybody
will
agree.
That's
how
you
want
to
do
it
once
we've
gotten
past
that
point,
then
registries
want
to
start
upgrading
their
stuff.
A
It's
going
to
be
extended,
though
it's
going
to
have
that
reference
type
in
there,
so
you
can
still
have
the
api
for
the
references,
query
that,
and
so
we
can
find
these
references
quickly
using
the
api.
You'll
get
some
speed
benefits
there,
but
we
still
have
the
backwards
compatibility.
When
you
copy
this
artifact
to
a
registry,
it
doesn't
support
the
new
manifest
well
we're
still
pushing
the
image
manifest.
There's
nothing
new
in
there.
You
push
the
digest
tag.
A
A
A
So
here
are
the
modifications
I
need
to
sort
some
stuff
out,
but
I
had
a
couple
of
extra
annotations
in
here
saying:
here's
the
artifact
type
pulling
in
from
proposal
c,
I
put
the
description
in
there
and
then
the
create
a
time
stamp.
So
I
think
those
were
some
different
annotations
that
we
were
looking
at
from
different
places
got
all
those
included.
A
I
was
trying
to
go
through
and
look
at,
maybe
other
stuff
that
was
in
the
config
today,
and
the
only
thing
I
could
see
that
might
be
useful
is
the
platform
might
be
useful
in
there
for
some
use
cases.
A
So
I
wasn't
sure
if
we
want
to
pull
that
up,
and
the
other
thing
I
was
looking
at
was:
do
we
want
to
take
all
the
stuff
that's
out
there
today,
that
is
org,
open
containers,
image,
star
and
maybe
find
a
more
generic
name
for
that,
since
we're
trying
to
push
generic
artifacts,
maybe
there's
some
stuff
up
there.
A
I
don't
think
it's
something
we
need
to
agree
to
from
this
proposal,
but
it
might
just
be
something
that
we
propose
up
to
oci
after
this
saying:
hey,
if
you
like
this,
here's
a
little
side,
pr
that
we
want
to
merge
as
well
and
let's
see
anything
else
in
there,
any
additional
things
feel
free,
throw
them
out
there.
We
can
always
add
more
of
this.
This
is
a
free
form
list,
so
we
can
always
extend
this.
We
need
to
json
schema
here
if
we
look
at
the
image
manifest.
A
So
this
is
the
original
oci
image
manifest
all
the
stuff
up
top
is
pretty
much
the
same.
Annotations
are
the
same.
The
reference
field
is
the
one
thing
is
new
and
then
the
annotations.
This
would
be
the
annotations
for
the
artifact
itself,
and
so
anything
you
put
in
like
the
artifact
type
that
would
go
down
here
and
then
the
reference
gear,
like
I
say
that
is
new,
and
as
long
as
we're
following
the
oci's
extensibility
requirement
that
we
add
a
new
field
in
there.
A
D
Oh
yeah,
this
was
a
comment
from
before
about
the
annotations.
We
may
also
want
os
version
which
occasionally
comes
up,
but
when
it
comes
up
is
important.
D
Under
platform
there's
an
os,
it's
really
confusingly
called
os
dot
version,
even
though
it's
not
a
subfield
under
os.
Anyway,
it's
for
like
windows,.
D
B
If
you
are
putting
a
reference
in
I'm
just
wondering
you
know,
what's
the
dance
here
and
how
do
you
do
validation
that
you
indeed
have
a
an
intact
set
of
metadata,
because
these
seem
load-bearing,
I
don't
know
if
they
are
or
if
that's
your
intent,
but
if
they're
outside
the
reference
object,
do
we
need
to
do
anything
special
and
say
that
you
must
have
these
annotations
if
you
have
a
reference
field
or
are
they
purely
optional
and
in
order
to
enrich,
because
I
can
imagine
if
you're
doing
any
filtering
on
artifact.type-
that's
not
present,
you
can't
obviously
do
that.
A
My
take
right
now
is
that
this
can
actually
be
optional
and
so
reference
itself
that's
kind
of
the
one
thing
you
absolutely
need
to
throw
in
there.
A
The
digest
tag
you'll
absolutely
need
that,
if
you're
on
a
old
registry-
and
that
gives
you
the
link-
but
once
you
have
that
link,
if
you
say
query
all
the
artifacts
out
there
without
any
filtering
you'll,
just
get
all
the
artifacts
if
you're
filtering-
and
you
want
to
be
seen
in
that
filter,
you're
going
to
have
to
put
the
field
in
there
someone's
going
to
filter
on
it.
So
you
need
to
use
the
right
label
in
there.
G
A
A
F
A
Yeah
yeah,
okay,
we'll
revisit
that
one
and
it's
a
good
question
because
I
think
a
lot
of
people.
I
think
it
should
be
at
least
a
should
at
a
minimum
and,
let's
see
so
yeah,
we
talked
about
the
image
manifest.
It's
gonna
have
the
required
reference
field
in
there.
This
looks
pretty
much
the
same
as
we've
seen
before.
A
I
am
pulling
up
annotations,
that's
kind
of
a
debatable
subject
there,
but
if
this
thing
is
referencing
something
else,
you
could
potentially
pull
up
those
annotations
for
filtering
yeah
if
there's
a
need
to
in
there,
and
so
that's
kind
of
the
question
of
where,
where
do
we
need
to
pull
it
up?
Where
don't
we
need
to
pull
it
up
and
I'm
trying
to
think
right
now?
If
I
actually
need
to
do
it
in
this
one
or
not,
I
might
not
actually
need
it
right.
There
brandon.
F
I'd
get
better
off
is
the
assumption
there
in
that
section
that
you're
pulling
up
the
manifest
annotations
so
that,
for
instance,
artifact
type
would
show
up
there
like.
So,
if
I
had
that
that
reference.
A
A
Yes,
yes,
in
that
case,
it
would
be,
but
right
here
I
might
have
said,
pull
up
a
little
bit
too
soon.
I
might
not
actually
need
them
right
here,
but
we'll
see
jason.
You
got
one.
D
Yeah,
anytime,
we
talk
about
pulling
up
annotations
from
other
things,
like
tools
can
do
this
tools
should
do
this,
but
what,
if
they
don't
or
what?
If
one
case
is
what,
if
they
don't
put
something,
don't
pull
up
an
annotation,
but
even
worse
is
like
what
happens
if
they
put
the
wrong
annotation
value
in.
A
Yeah
all
right,
let
me
let
me
start
with
the
assumption
right
here
that
this
was
a
typo
or
a
brain
okay,
and
so
we
don't
do
it
right
here.
These
annotations
are
the
ones
you're
actually
attaching
to
the
artifact
and
below.
I
actually
do
need
to
pull
them
up,
but
it's
not
the
tool,
that's
pushing
the
artifact,
it's
the
tool,
that's
generating
the
manifest
list.
D
A
Yep
good
points,
though,
all
right,
so
here
is
our
new
media
type.
I
just
called
it
artifact
manifest.
I
think
I
copied
that
from
proposal
a
I
put
blobs
in
there
I
put
annotations
in
there.
These
are
the
annotations
on
artifact
and
blobs
are
optional.
A
There
is
no
config,
and
these
can
be
unordered
ordered
just
depends
on
what
you
need
in
here.
Sorry,
blobs
onward
or
just
depends
on
what
you
need
inside
of
the
blobs
and
the
reference.
Of
course,
that's
it's
optional
to
have
a
reference
on
your
artifact,
but
more
than
likely
all
the
artifacts
are
going
to
have
a
reference
to
whatever
they're
for,
but
you
could
always
push
up
a
standalone
artifact
that
doesn't
have
one
if
it
didn't
need
one
jason,
what
you
got
or
something.
B
A
A
If
you
query
this
and
doesn't
exist,
I'm
pretty
sure
all
registries
are
going
to
come
back
to
you
with
like
a
404
or
something
like
that.
You
can
just
double
check
that
part
and
make
sure
what
that
error
code
is
going
to
be.
It
doesn't
exist,
but
if
that's
confrontational,
we
can
always
put
it
back
under
the
extensions
for
personalized
figure.
This
was
something
big
enough.
A
Obviously
I
could
just
say
here's
what
we're
making
and
for
this
the
output
that
I'm
getting
is
an
index,
so
I
didn't
feel
I
was
basically
a
little
bit
too
lazy
didn't
feel
like
making
a
whole
new
media
type
for
this.
So
I
just
piggybacked
on
assisting
me
type.
I
thought
that
might
be
a
little
bit
easier
on
some
clients
that
already
had
this
structure
already,
and
so
they
pull
in
an
index
and
they've
got
a
manifest
list
in
there
and
then
annotations
might
be
some
metadata.
A
The
registry
gives
about
the
stuff
that
it
has
in
there
and
then
these
annotations
are
generated
from
the
registry.
These
are
the
ones
that
are
pulled
up
and
so
that's
kind
of
what
we're
getting
at
so
we'll
have
the
ice
cream
artifact.
Maybe
you'll
have
a
chocolate,
mayo,
vanilla.
Maybe
you
want
to
filter
and
say
I'm
only
interested
in
the
chocolate
ice
cream.
You
can
do
that
kind
of
stuff
in
a
bit.
We'll
show
that
and
so
I'd
just
say
you
know
for
a
given
reference,
and
this
could
be
a
tag.
A
This
can
be
a
digest.
Show
me
everything
out
there.
That
has
a
reference
point
to
it,
and
the
registry
comes
back
with
this
magical
list.
If
we
need
to
paginate,
have
multiple
pages
returned,
you
can
say,
give
me
up
to
in
and
it'll
cap
it
in.
A
A
If
it
does
do
something
like
that,
we'll
always
have
a
link
into
that
link.
Http
header
kind
of
the
standard
http
way
we've
seen
in
other
parts
of
oci
of
how
to
say,
grab
your
next
set
of
results
over
there
just
follow
that
link
and
pull
it
out
and
yeah.
So
we'll
just
get
back
multiple
indexes
from
that
list.
D
D
Can
you
scroll
up
a
bit
to
oh?
I
remember
you
mentioned
that
that
ref
could
be
a
tag.
D
I
think
we
should
prefer
to
only
accept,
digest
there
and
make
it
up
to
the
client
to
resolve
the
type
that
tagged
to
the
digest
as
a
separate
operation
rather
than
letting
the
registry
do
it
for
you
yeah
I
mean
I,
I
don't
want
people
to
get
used
to
looking
these
things
up
by
tag
because
it
will.
It
has
subtle
semantic
differences.
B
Lucky
I
was
just
gonna
ask
for
this
api
that
you're
proposing
here
does
it
matter
if
the
index
is
constructed
from
the
new
manifest
or
the
existing,
you
know
references
field
that
you're
adding
to
existing
images.
B
Because
you
could
have
some
of
it,
be.
You
know,
from
the
from
the
references
field
in
that
you're
adding
and
you
could
have
some
of
it
from
the
new
manifest.
A
Yeah,
I
didn't
change
any
of
that.
I
kept
them
identical,
otherwise,
just
gonna
say:
hey,
I've
got
a
new
artifact
manifest.
It's
got
this
digest,
it
has
a
reference
to
x,
and
so
you
query
x,
you
say,
give
me
the
stuff
for
x.
It's
going
to
say
here.
Is
the
image
manifest
or
the
artifact
manifest
down
here
with
those
annotations,
the
artifact
manifest.
Has
this
size
as
digest?
A
F
B
Yeah,
I
think
so
because
well
I'm
I'm
trying
to
get
to
how
do
you
start
whether?
How
does
the
client
understand
if
it
has
that
new
manifest
api
on
the
registry?
Does
it
have
to
just
try
and
push
and
generate
it
and
then
say?
Oh
I
don't
I
don't
have
that
or
if
you
query
this
end
point,
do
you
get
well,
you
only
see
things
from
the
reference
of
images
or
do
you
see
them
coming
from
it's?
It's
got.
You
flattened
it
out.
So
it's
not.
A
My
thought
process
right
now
is
you're
going
to
push
artifact
up.
You
can
query
this
api
and
say:
hey.
Did
I
get
a
response
back
from
my
artifact
that
has
pushed
yes
or
no?
If
it
comes
back
and
says
404,
I
can't
find
it
that's
when
you're
going
to
say:
oh
this
registry
doesn't
have
it.
Let
me
push
a
digest
tag
now
and
so
that's
a
way
of
doing
it.
There
could
be
other
ways
we
could
query
the
the
oci
extensions
field
and
maybe
they'll
throw
an
extra
thing
in
there.
A
F
I
think
when
you
push
through
a
registry
you
push
to
a
manifest.
The
registry
has
to
know
like
there's
relaxation
of
blob
media
types,
because
mostly
it
doesn't
matter,
but
the
manifest
registries
do
need
to
know
because
they
know
how
to
parse
them.
So
if
you
try
to
submit
a
branded
manifest,
the
registry
is
going
to
like.
I
don't
know
what
that
is
and
give
you
an
error
back.
So
you
you
would
know
there
whether
you
can
continue
or
not.
A
A
F
F
F
A
F
I'm
not
following
that
yeah.
What.
F
F
You
know
image
and
you
get
all
the
references
to
that
ice
cream,
v1,
v,
strawberry
image,
whether
the
digest
comes
back
as
abc
or
456.
It
doesn't
really
matter
so
you
can.
You
can
actually
round
trip
them.
A
If
I'm
synchronizing
two
registries
together,
if
I'm
setting
up
like
a
hand,
built
mirror-
which
is
one
of
the
things
I
kind
of
do
I'll
copy
the
image
over
and
I'll
see,
does
the
image
digest
already
exists
in
the
target
registry?
Yes,
no,
and
if
that
digest
for
the
whole
image
exists,
I
know
that
I'm
kind
of
done.
I
can
skip
the
next
part.
If
I
then
query
all
the
artifacts
point
to
that
image,
I'm
going
to
query
to
see.
A
H
A
couple
of
there
was
a
statement
that
I
wanted
to
clarify,
which
was
do
we
need
to
push
and
digest
or
anything
like
that,
I'm
hoping
we
don't
have
to
do
any
push
operation,
because
that
would
be
different
apple
sets
right.
You
don't
you
want
to
make
sure
that
the
permission
sets
don't
have
to
be
worried,
so
just
defining
how
a
user
can
be
that,
like
deterministic
find
out
okay,
I
don't
have
references
404
versus
empty
list,
maybe
adding
that
to
the
specification
definitely
helped.
A
A
H
Yes,
in
both
cases,
yes
sounds
good.
The
second
question
was:
do
you
anticipate
that
does
this
scenario
require,
like
one
client,
to
move
content
between
two
types
of
registries,
one's
that
support
new
manifest
and
not,
or
are
we
kind
of
like
saying
that
that
is
not
something
that
we
want
to
address
with
this
I'm
okay,
I
do.
I
just
want
to
kind
of
clarify
what
this
package.
A
My
goal
right
now
is
as
long
as
you
think,
you're
going
to
have
registries
of
both
types
out.
There
you're
going
to
keep
all
of
your
manifest
within
the
old
image,
manifest
descriptor
and
that
will
be
portable
across
registries,
and
then
you
would
only
upgrade
to
this
new
artifact
manifest
once
you
know
that
all
the
registries
you're
working
with
and
hopefully
all
the
registries,
your
end
users
are
working
with
have
been
upgraded.
A
Sound
good,
okay,
yeah,
so
pagination.
I
think
we
hit
a
little
bit
on
that.
We
got
the
link
field,
filtering
and
sorting,
I
think,
is
going
to
be
the
big
question
here.
The
registry
should
support
this
filtering
and
I'm
just
going
to
say
url
code
like
a
name
equals
value.
A
I
might
want
something
other
than
just
equal.
I
might
want
like
a
double
equal
in
there
because
of
some
of
the
thoughts
that
come
up
here
later
on,
which
is.
Do
I
want
to
support
less
than
greater
than
maybe
some
kind
of
prefix
other
things
like
that
that
might
come
into
play
of
changing
whatever
this
operator
is
in
the
middle
of
what
that
looks
like
and
whether
we
support
they're,
not
whether
we
want
to
allow
registry
support
they're.
Not
we
can.
We
can
chat
about
that
at
least
for
right
now.
A
A
Let's
see
that's
kind
of
my
thought
process.
There
questions
on
filtering
right
now
we
can
probably
go
through
and
debate
those
later
on.
I
think
this
is
going
to
be
it's
kind
of
thrown
out
here
a
little
bit
loose,
but
that's
kind
of
the
rough
idea
is
that
all
the
filters
can
be
done
on
annotations,
so
you
can
filter
whatever
you
want
to
whatever
makes
the
most
sense,
depending
on
how
that
artifact
was
pushed
up.
A
So
that's
going
to
be
a
negotiation
between
the
client
doing
the
pushing
and
the
client
doing
the
pulling
they're
going
to
know
how
those
annotations
were
set
on
top
of
their
artifacts,
which,
because
that's
kind
of
an
agreement
between
those
two
halves.
That's
why
I'm
leaving
a
little
bit
loose
where
it
should
put
the
artifact
type
in
there.
But
if
your
client
knows
it's
doing
something
different,
then
I'm
not
going
to
enforce
that.
You
have
to
put
those
specific
specific
annotations
on
there.
A
A
G
A
This
is
hinting
for
the
people
that
are
doing
a
query
by
the
tag
list
to
know
which
things
they
need
to
filter
at
the
next
level,
and
I
can't
get
super
granular
in
here
and
put
the
whole
world,
but
I
can
at
least
get
granular
enough
that
you
can
pull
at
least
the
right
types
of
artifacts
and
hopefully
cut
down
your
search
a
little
bit,
and
so,
if
you're,
putting
up
bad
data
in
your
digest
tag.
Well,
you
just
kind
of
corrupted
yourself.
A
In
that
case,
I
can
only
help
you
so
much
so
if,
if
they
intentionally
hide
their
reference,
then
yeah
they're,
I
can't
do
anything
there.
If
they
intentionally
put
a
bad
digest.
I
can't
help
them
with
that
either.
But
it's
just
kind
of
the
goal
is
to
help
you
reduce
the
search
space.
You
have
to
look
for
to
find
your
artifact.
G
Yeah
I
am
bringing
that
up
because
I
get
nervous
about
like
strings
and
you
know
relying
on
strings
to
tell
you
what
you
are
downloading
from
the
internet.
G
Yeah,
but
in
order
to
but
you're
still
relying
on
some
bits
of
this,
like
you,
you,
the
hash
must
be
correct.
The
digest
must
be
correct.
A
G
A
G
Oh
so
you're
saying
that
the
the
artifact
producer
does
not
make
this
tag.
It's
the
repository
that
makes
this
tag.
A
G
F
Steve
yeah,
I
think
what
you're
suggesting
is
that
the
client
tools
do
this.
Whatever
tools
that
are
trying
to
push
the
reference
types
would
do
this
combination
of
stuff,
because
nothing
stops
a
user
from
using
like
an
aura's
client
to
go,
you
know
or
as
push
and
then
here's
some
funky
log
tag.
But
if
I'm
pushing
a
reference
type
I
say:
here's
the
s-bomb
I'm
trying
to
submit
and
it
does
the
right
thing
it
sees.
The
registry
doesn't
support
it
and
it
sticks
in
the
tag.
F
B
B
My
tag
listing
is
full
of
crap
and
I
can't
now
see
what's
there,
and
so
I
think
just
you
know,
hopefully
leaving
the
tags
here
and
having
all
the
string
stuff
is
going
to
upset
you
sufficiently
in
nature
that
you'll
go
and
implement
the
the
new
manifest
type
on
your
registry
and
say
well,
you
know
you
know
you.
We
can
do
this
way
so
that
you,
your
tag
listing,
isn't
polluted.
B
C
So
I
I
I
feel,
like
the
big,
the
big
value
of
this
one
is
the
upgrade
path
and
kind
of
the
compatibility,
and
I'm
wondering
if
you
can
sort
of
speak
to
what
are
the
primary
differences.
I
think
I
see
some
but
for
not
pulling
in
the
api
used
in
proposal
a
and
instead
doing
something
different
there.
I'm
just
I'm
I'm
thinking
about
like
bridging
the
gaps
here
and
yeah.
A
C
A
I'm
gonna
hit
on
the
digest
tag,
changes
real,
quick
and
I'm
going
to
go
back
up
to
the
registry
api
because
I
did
some
on
both
so
on
the
digest.
Just
real
quick
for
anybody
who's
not
familiar.
You
query,
you're,
looking
for
everything
that
has
a
reference
to
your
zero
zero,
zero,
zero,
zero
you'll.
Do
a
tag
list,
find
everything.
A
That's
got
that
prefix
and
maybe
it's
got
the
suffix
you're
looking
for
and
this
little
hash
in
the
middle
just
makes
it
unique
and
you
just
pull
up
all
those
tags
and
then
I'm
just
saying
put
it
out
just
type
for
everything's
got
a
reference,
doesn't
matter
if
you're
the
put
a
reference
in
index
or
put
a
reference,
wherever
just
put
it
at
your
site
for
everything.
A
Now
going
back
up
to
the
registry
ap
yeah
up
here
in
the
registry
api,
I
did
move
it
over.
The
biggest
difference
I
think
I
made
was
that
I
just
made
the
filtering
all
based
on
annotation
instead
of
having
a
separate
filter
on
artifact
type.
I
think
that
was
the
biggest
difference
of
all
that
I
made
over
there
and.
C
Even
the
reason,
even
the
like
the
end
point
is
references
versus
referrers
and
the
the
output
is
an
index
which
I
don't
I
don't
mind,
but
the
I'm
just
looking.
I
have
a
pulled
up
side
by
side
here
and
it's
and
then
sorry,
while
I
have
my
mic
on,
would
this
list
also
include
the
new
artifact
schemas
within
yes
side
by
side?
Okay,.
B
So
he
popped
that
down
into
the
annotation,
and
you
know
that
api
returning
an
index
rather
than
just
a
collection
of
manifests.
A
It
was
less
not
wanting
to
extend
it
and
more
that
I
didn't
get
any
value
by
putting
it
as
a
separate
field.
It
just
kind
of
felt
like
we
were
treating
that
one
thing
special
where
I
want
to
just
be
able
to
filter
on
everything,
and
so,
if
I
was
going
to
have
to
do
that,
I
might
as
well
just
not
have
an
extra
exception
for
that.
One
artifact
type
field.
A
I
I
did
leave
this
annotations
here.
I
said
kind
of
optional,
but
I'm
envisioning.
This
is
kind
of
the
place
that
someone's
going
to
come
in
and
say:
hey,
I'm
the
registry,
as
gave
you
back
the
results
for
these
things,
and
so
may,
if
you
query
all
these
filters
and
do
weird
filters
doesn't
know
about
it's
going
to
say,
here's
a
list.
I
gave
you
these
filters
and
nothing
else,
and
so
maybe
you
look
at
this
and
say:
did
I
see
all
the
annotations
I
expected?
A
A
I'm
leaving
that
a
little
arbitrary
for
right
now,
but
that'll
kind
of
be
up
to
us
to
come
back
later
on
and
say
here
are
the
fields
we
want
to
put
in.
Maybe
that's
just
a
base64
encoded
string,
or
maybe
it
comes
up
with
a
whole
bunch
of
individual
keys
and
values
for
different
stuff.
A
All
right,
so
that's
the
goal
that
we
get
to
references
with
that
api.
The
fallback
is
the
digest
tags
that
we
can
say
this
will
work
with
the
registry
a
and
then
I've
gone
through
already
and
kind
of
put
a
bunch
of
requirements
of
what
I
thought
that
we
are
going
to
have
the
ability
to
do.
Does
anybody
want
me
to
talk
about
a
specific
one,
because
I
don't
think
we'll
go
through
each
one
of
these
individually
in
15
minutes
and
still
have
time
to
talk
about
other
stuff.
H
I
added
it
to
the
notes,
so
the
hash
portion
of
the
tag
right
that
one
is
not
collision
free,
because
when
you
move
it
from
registry
to
registry,
given
how
many
hashing
implementations
I've
seen,
people
would
go
index
like
increment,
hash
and
whatnot,
and
if
you
are
first,
if
you
do
a
signature
in
one
place
and
then
move
it
over
to
another,
and
you
have
your
own
signatures,
those
hash
numbers
are
going
to
be
unique.
Is
there
a?
Is
there
a
recommendation
that
you
want
to
give
that
these
hashes
have
to
be?
A
So
this
is
the
hash
of
your
artifact,
not
your
digest
that
you're
pointing
to
without
the
artifact
you're
pushing,
and
so
it
should
be
the
hash
of.
Let's
go
back
up
here
of
the
manifest.
A
By
doing
that,
though,
keep
in
mind
that
this
tag
we're
only
carrying
that
this
tag
doesn't
collide
right
right.
I
don't
care
that
this
individual
hash
right
here
doesn't
collide.
We
care
about
this
entire
tagline,
which
means
you've,
got
the
reference
that
you're
pointing
to
plus
this
hash,
and
so
by
having
both
there.
A
H
A
H
A
F
A
I
had
a
couple
in
here
that
said:
partial,
let's
see,
if
any
of
those
were
important
here,
nisha
go
ahead.
G
Yeah,
I
I
didn't
quite
get
understand
the
reply
for
josh's
question.
Why
change
the
api
names
from
proposal
a
like?
Why?
Why
not
referrers,
instead
of
references.
A
I
was
just
moving
there
and
the
main
reason
I
picked
references
was
because
the
field
itself
was
called
reference
and
so
kind
of
felt,
like
keeping
those
two
together
logically
made
sense
to
me,
but
it's
at
that
point
of.
If
that's
the
only
thing
that
people
wanted
me
to
change,
I'm
happy
to
change
it.
A
A
I
want
to
apply
a
timestamp
or
numerical
arranged
artifacts,
and
so
I
said
partial
on
that
one
that
you
can
put
whatever
you
want
in
those
annotations
and
then
do
filters
on
that
right
now.
If
my
filter
is
only
equals
that
doesn't
work
so
we'll
need
some
sorting
in
there,
but
I
think
we've
got
what
you're
looking
for.
If
it's
a
digest
tag,
you
just
have
to
follow
the
sites
that
match
whatever
you're.
Looking
for
and
then
query
within
each
one.
G
Yeah,
this
should
work.
A
And
then,
as
an
artifact
arthur,
I
want
to
document
artifacts
one
or
more
registries
that
have
my
artifact
and
that
my
artifact
requires
or
provides.
So
I
think
this
was
the
cross
registry
scenario
and
so
to
go
across
registry.
The
references
api
is
not
cross.
Repository
even
you've
got
to
be
in
the
same
repository
for
the
references
api
to
work,
just
keeping
within
what
everything
else
in
oci
is
today.
A
C
Considering
it
it's
not
even
submitted,
I
think
we
ought
to
stick
on
this
topic
or
I
can
bring
it
up
next
week.
Actually,
I
won't
be
here
next
week,
so
I
can,
if
you
want,
let's.
C
B
C
So
this
was
shared
to
me
from
somebody
who
wanted
to
remain
anonymous
because
they
did
not
feel
that
they
they
thought
this
would
be
torn
to
shreds.
And
I
told
them
you
should
have
more
confidence
and
were
much.
C
Nicer
than
you,
but
anyway
it's
it's.
Basically,
it's
based
on
proposal
b,
and
I
talk
to
them
about
what
are
the
primary
differences,
and
there
are
the
biggest
thing
that
I
could
see
is.
One
is
query.
Query
parameters
having
like
super
advanced
type
of
not
equals
like
brandon
was
alluding
to
so
it's
not
just
equals
this,
and
then
the
other
one
was
a
sort
of
top-level
query.
C
So
what
they
were
saying
is
that
the
I
think
the
quote
was
like
oci
makes
things
extremely
hard
for
sort
of
an
end
user
to
if
I
want
to
come
to
the
registry
and
search
for
like
this
is
saying
like
what
anything
related
to
chocolate
or
with
chocolate
in
the
name.
I
only
have
access
to
what's
in
the
name.
C
Space
and
everything
we're
designing
around
is
around
the
name
space,
and
I'm
already
thinking
like
from
a
registry
operator
like
this
is
sort
of
there's
like
a
privacy
concern
and
there's
an
access
thing,
and
so
this
was.
This
was
really
the
big
differentiator.
A
For
the
operators,
what
I
was
seeing
in
other
places
was,
they
were
saying
where
the
equal
equal
was.
They
were
just
swapping
that
out
with
like
greater
than
equal,
less
than
equal
a
couple
other
parameters
in
there,
and
so
they
had
different
things
in
the
middle.
F
Well,
this
is
the
same
thing.
We
saw
a
proposal
be
earlier,
so
if
you
scroll
up
a
bit
to
where
the
result
is
where
the
different
ice
creams
that
come
back
in
the
result,
the
manifest
collection,
the
the
descript
sorry
yeah
there
we
go
lag.
So
if
that's
the
result
of
the
references
referrers
api,
whatever
the
things
that
come
back,
what
I'm
confused
about
this
is
the
media
type.
F
In
that
manifest
those
there
are
that's
suggesting
there's
there
are
yet
newer,
manifest
types
as
opposed
to
artifact
types,
because
I
think
what
we're
trying
to
say
is
I
want
to
have
of
like
we're
not
trying
to
have
dozens
of
manifest
support
in
the
registries.
It's
we
want
to
have
maybe
one
more
manifest
type
to
be
able
to
support
the
new
functionality.
C
F
F
C
I
guess
just
so.
I
can
like
fully
understand
the
concern
around
something
like
this,
like.
I
understand
the
desire
for
something
like
that
that
isn't
this
sort
of
almost
not
implementable,
like
from
a
open
source.
I
mean
it's
not
not
implementable,
but
is
this
sort
of
out
of
scope
for
us.
C
F
Oh,
I
I
think
searching
an
entire
registry
for
stuff.
Whatever
I
add
permissions
to
is
hugely
valuable,
but
I
think
that
those
are
on
I'm
guessing.
Those
are
on
annotations,
which
yes,
you'll,
probably
filter
by
media
type.
Also,
but
like
give
me
all
the
scan
results
that
you
know
from
within
the
last
week
or.
B
I
think
sanjay
and
brandon
are
touching
on
something.
It's
like.
We
need
a
separate
working
group
just
for
search
and
filter,
because
this
is
more
a
meta,
a
matter
issue
of.
Do
you
want
to
implement
this
kind
of
functionality
in
general,
outside
the
scope
of
references?
So
I
don't
I
mean
this
is
going
to
have
to
depend
on
that.
I
would
guess,
but
anyway
sorry,
brandon
yeah.
A
I
got
two
things
in
there.
I
think
I
can
get
in
five
minutes
here.
One
is
that
the
query
syntax
there,
the
queue
manifest
media
type
contains.
I
think
we
probably
want
to
change
it
to
just
field
equals
and
the
value,
and
that
value
has
a
bunch
of
stuff
that
gets
extracted.
That
just
makes
it
easier
for
all
the
different
http
libraries
to
parse
that
apart
so
still
doable
just
by
a
little
reformat
there,
but
otherwise,
knowing
in
oci
how
authentication
is
done.
A
B
Yeah
I
agree
with
that
josh.
I
agree
with
that.
Okay,
it's
just
at
the
moment,
we're
kind
of
just
saying:
leave
it
up
to
the
client
to
implement,
there's
everything
there
to
construct
a
search
and
filtering
thing,
but
how
you
do
it
is
up
to
the
reader,
an
adventure
for
the
reader.
If
you
want
to
make
that
codified
in
a
set
of
apis
that
are
server-side,
that
can
certainly
be
done
and
then
the
clients
can
be
a
lot
more.
B
They
don't
have
to
deal
with
all
that
or
implementing
all
that-
and
I
do
you
know
I
don't
that
I
feel
like
that's
a
discussion
that
could
be
possibly
had.
F
B
F
It's
not
actually
the
registry
operators
per
se.
This
was
actually
it's
all
clients,
because
basically
it's
permissions
challenge,
but
I
I
actually
don't
necessarily
agree
if
you,
if
you're,
deploying
a
helm,
chart
or
any
kind
of
service
in
a
kubernetes
cluster
you're
trying
to
pull
multiple
images,
you're,
assuming
your
permission
to
those
multiple
images,
it's
the
problem
has
been
more
of
when
I
promoted
across
registries.
Do
I
want
to
store
them
in
the
same
place?
F
B
Through
a
lot
of
struggles,
okay,
let's,
let's
wrap
on
time,
I
would,
if
you
so
you're
not
here
next
week,
josh.
C
No
but
yeah,
I'm
wondering
I
I'm
also
curious
where
we
go
from
here,
considering
we're
done
with
proposals,
yeah.
B
B
B
Is
that
what
we're
going
to
go
ahead
with,
and
as
everybody
considered
it,
because
I
see
a
lot
of
people
on
this
call,
I
want
to
make
sure
everybody's
considered
it.
You
know
before
we
before
we
go
ahead,
so
maybe
it's
just
even
a
call
to
consideration
around
proposal
e
as
to
being
the
proposal
we
want
to
move
forward
with
and
then
ask
anybody
to
request
for
comments.
C
I
will
just
open
an
issue
on
the
repo
about
search
and
filter
for
the
future
and
okay,
we'll
go
from
there
all
right
yeah.
That
sounds
great.
I'm
I'm
so
excited
that
we
got
to
this
point
somehow.
It's
april.
B
So,
let's
yeah,
let's
see
what
next
steps
and
let's
just
punt
it
out
to
a
conversation
and
see
what
we
can
get
on
an
agenda,
but
we
should
start
to
kill.
You
know
to
coalesce
in
a
specific
direction.
So
it
is
what
I'd
like
to
encourage
everybody
to
start
thinking
about.
What's
it
going
to
take
to
put
our
rubber
stamps
on
this
and
ship
it
up
to
the
tob.
B
I
B
Excellent
well
thanks
folks-
and
I
do
you
know,
encourage
the
folks
that
didn't
have
a
chance
to
speak
today
that
are
on
the
call
that
would
like
to
provide
feedback.
Please,
please
do
we'd
love
to
hear
it.