►
From YouTube: [OCI-WG] Reference Types - 2022-04-19
A
C
Me
too,
I
did
hear
I
guess
I
missed
the
oci
meeting.
I
heard
that
we
presented
it
there
or
you
presented
there
too.
A
Yeah,
I
kind
of
gave
a
quick
rundown
of
it.
My
goal
of
talking
about
over
there
was
just
to
get
feedback
from
them
of
anything
that
we
might
be
missing
on
our
side
that
we
want
to
include
when
we
present
it
later
on
so
yeah.
What
in
a
formal
presentation
was
just
hey
here's.
What
we're
thinking
of
doing
is
there
something
we
need
to
do
for
you
before
we
put
this
together.
A
A
C
A
Yeah
and
to
some
degree,
you
know
you
throw
a
big
proposal
over
there
and
just
say:
hey
here's.
What
we're
thinking
of
I
think
a
lot
of
the
time
people
might
just
be
spending
reading
through
it
saying
what
on
earth
is
he
asking
us
to
do,
and
so
some
of
that
might
just
be
shell
shock
or
just
too
much
detail
there
at
once,
but
yeah.
My
overall
goal
is
just
to
make
sure,
especially
you
know.
A
I
think
a
lot
of
people
have
been
giving
thumbs
up
to
this
before
been
more
the
end
user
side,
and
I
want
to
make
sure
we
make
that
we
include
the
registry
operators
too,
of
hey.
This
all
looks
great
from
a
client
side,
but
when
we
try
to
implement
this
on,
the
server
might
be
issues.
So
I
want
to
weed
any
of
those
out
earlier,
rather
than
later,.
A
A
C
C
I
think
the
thing
that
I
think
is
I
don't
know
new
and
a
little
scary
is-
is
just
filtering
on
any
annotation
sort
of
thinking
through
how
that
gets
implemented.
With
with
the
lack
of
constraints
on
the
annotation
fields
and.
C
I
think
the
the
the
the
way
I've
been
thinking
about
it.
We
would
maybe
pick
a
couple
filterable
things
that
registries
should
pull
out,
but
not
necessarily
allow
any
annotation
to
be
filtered
on.
A
Yeah
and
so
for
that,
I'm
thinking
back
to
all
the
the
requirements
questions.
I
know
there
are
a
couple
in
there
that
are
there
saying
you
know,
kind
of
sort
by
arbitrary
dates
and
other
versions,
and
things
like
that
now
I
try
to
get
as
close
as
possible
without
putting
too
much
overhead
on
the
registry
operators,
but
I'm
sure
I'm
sure,
there's
ways
we
can
make
this
better
for
you.
A
A
B
A
That
said,
one
of
the
things
I
did
in
here
was
included
in
the
response
back
to
the
client.
This
is
what
I
did
filter
on,
so
the
server
says
you
asked
me
a
filter
on
these
six
things.
A
I
gave
you
two
of
them
and
I
left
that
in
there,
knowing
that,
if
we
come
into
the
situation,
the
filter
was
always
a
should.
It
was
never
a
must,
and
so
the
server
comes
back
and
says
yeah
I
filtered
on
these
two
things
that
you
gave
me
the
client
can
then
say.
Okay,
I
didn't
get
everything
I
asked
for.
A
B
B
A
Yeah
the
artifact
pretty
close
to
what
they
had,
I'm
not
sure
if
I
added
many
changes
in
there
other
than
just
all.
I
was
the
reference
I
didn't
add
the
artifact
type
field
that
we
were
talking
about
before.
B
B
Yeah,
I
guess
from
my
perspective,
you
can
go
through
proposals
like
you
know,
a
through
z,
but
the
one
that
wins
is
the
one
that
shows
that
the
implementation
is
feasible
and
yeah
I
mean
I,
I
think
your
approach
here
makes
sense
to
almost
just
implement
both
the
image
spec
and
the
artifact
spec,
and
maybe
one
of
them
will
disappear
in
the
final
version.
A
A
Because
you
never
know,
sometimes
people
want
to
sometimes
people
look
at
these
recordings,
probably
just
vincent
on
his
own
yeah,
and
I
did
get
some
questions
a
few
times
on
yeah
we're
talking
about
two
things:
we've
got
the
image
manifest,
but
we've
also
got
the
artifact
manifest
and
does
it
make
sense
to
modify
damage
manifest
with
this
reference
and
not
change
the
version
number
not
do
anything
else
to
it.
Are
we
breaking
any
of
the
promises
that
this
is
all
version
data?
A
Are
we
screwing
with
the
artifact
manifest
or
the
image
spec
we
shouldn't
be
able
to,
and
I'm
hoping
that
we
are
able
to
get
that
through,
as
is
because
I
just
know,
there's
going
to
be
someone
out
there,
that
is
looking
at
version.
1
schema
version
2
here
and
if
we
change
these
version
numbers,
if
we
do
anything
else
to
modify
this
to
look
different
so
that
we
make
this
different
from
what
it
is
today
will
break
existing
clients.
A
B
Yeah,
it's
tricky.
I've
been
against
this
approach
from
the
beginning,
but
it's
it's
it's
my
opinion
on
it.
That's
why
I
feel
like
this
working
group's
responsibility
is
to
figure
out
how
feasible
it
is.
What
are
the
edge
cases
of
doing
this?
I
I
mean
I
agree
like
it's
easier
from
the
standpoint
of
like
existing
registries.
B
Well,
shouldn't
have
any
issue
accepting
it
for
the
most
part,
but
I'm
not
so
sure
that's
just
like
slipping
features
in
invisibly.
I'm
not
sure
what
the
real
value
is
like
we're,
adding
a
new
feature
like
support.
I,
like
explicit
support
for
new
features.
You
know
it's
not
like
we're
trying
to
like
work
around
some
like
issue
when
you're
like
trying
to
work
around
something.
B
You
know,
then
these
sort
of
work
arounds
make
sense,
but
for
new
features
I
I
think
it
makes
sense
to
add
new
types,
but
so
that's
that's
my
opinion
on
it.
Yeah
and
I
think
you
know
in
the
end
like
we
should
make
a
decision
not
based
on
opinions
but
based
on
like
oh,
this
is
what
we've
shown
works.
A
Yeah
and
in
a
way
I
I
would
love
if
we
could
say
all
registries
are
forced
to
upgrade,
and
then
we
get
the
new
artifact
spec.
We
get
the
api
and
we're
just
done.
I
just
know
from
my
painfully
hard
experience
that
old
registries
stick
around
for
a
lot
longer
than
we
want
them
to.
B
Yeah
but
old
registries
don't
need
to
support
the
new
features.
I
guess
that's.
The
thing
like
the
problem
here
is
like
the
first
mover
approach
like,
like
we
add
support
for
this
like
who's
to
be
the
first
registry
to
implement
it
and
support
it.
Who's
gonna
be
the
first
client
like
it's
hard
like
and
in
the
past,
like
users
were
kind
of
forced
onto
it
by
upgrading
docker
to
things,
and
it
was
painful
and
it
took
a
long
time.
B
You
know,
and
it
took
like
you
know
one
company,
basically
forcing
it
on
the
whole
community
to
get
like
registry
two
out
there,
but
at
the
time
it
was,
it
was
really
controversial.
Like
yeah,
I
think
if
we
went
through
a
process
of
trying
to
trying
to
come
to
a
consensus
like
I
don't
think
it
would
have,
I
don't
know,
I
don't
think
a
consensus
ever
would
happen.
B
A
A
Field,
so
what
they're
doing
today
is
just
the
I
think:
they've
got
their
own
index
on
top
of
it
to
push
multiple
things,
but
they've
got
the
digest
tags
today
and
so
they're
working
with
the
image
spec
as
it
is
today,
they're
pushing
up
the
artifacts
up
there
in
image,
spec
and
they're.
Using
these
digest
tags,
they
don't
have
the
extra
hash
to
de-duplicate
things
so
they're,
I
think
they're
throwing
an
index
on
top
of
it,
but
yeah
as
much
as
I
want
to
say.
A
B
A
Yeah,
well,
I
think
the
way
I
went
with
this
was
just
to
formalize
a
lot
of
what
they're
doing
with
a
few
small
tweaks
and
that's
where
dan
jumped
on
the
pr
and
said
yeah.
It
looks
good
to
him,
so
I
think
I
think
we
kept
it
close
enough
to
what's
happening
there
right
now.
That
is
not
too
much
of
a
breaking
change
for
them
and
so
formalizing
what
they're
doing
and
then
saying?
Okay,
that's
great!
A
A
B
Field's,
probably
the
biggest
change
here,
the
art
or
like
adding
a
new
artifact
type,
I
think,
is
interesting.
B
I
would
like
to
see
that
happen,
but
when
we
talk
about
like,
what's
being
done
today,
it's
like
yeah
cosine's
doing
it,
and
then
a
lot
of
different
companies
are
doing
their
own
thing
for
implementing
a
lot
of
this
stuff
like
we
can't
like
we
can't
kind
of
like
standardize
them
all
like
if
the
approach
of
this
working
group
is
to
find
like
the
best
way
to
do
it
across
the
community.
B
I
mean
it's
hard
because,
like
oc
is
really
bad
at
building
novel
things
yeah
and
without
anybody
pushing
this
new
artifact
type,
I
I
struggle
to
see
how
it's
going
to
gain
traction.
A
I
think
there's
going
to
be
a
point
where
someone
take
build
kit,
the
way
they've
been
doing
their
stuff
today
and
throwing
their
cash
things
out
there
as
an
index,
instead
of
as
instead
of
as
an
image
with
blobs.
I
think
there's
any
point
that
some
tool,
like
that
says
great.
A
We
think
enough
registries
out
there
updated
we're
just
going
to
make
the
switch
over
here
to
this
one,
because
we're
tired
of
pushing
this
extra
config
blob,
my
guess
is
you're
going
to
start
seeing
a
couple
of
those
cases,
and
then
the
industry
is
just
going
to
say:
yeah
we're
tired
of
shipping
that
fake
blob
too.
Let's
just
make
the
change
yeah.
B
B
A
yeah,
I
guess,
if
you
can
get
docker
hub
to
do
it
and
some
of
the
clients
to
do
it,
then
you
know
that
will
be
motivation
to
get
other
registries
to
do
it,
I'm
not
even
sure
who's.
The
biggest
registry
today
like
where
everybody's
using
like
I
assume
it's
docker
hub,
but
you
know
it's
hard
to
it's
hard
to
say
like
so
many
different
registries
out
there
now.
A
B
B
C
B
Simple
index,
I
think,
realistically,
like
the
index
is
going
to
be
just
on
the
reference
and
then
it's
just
filtering
what
gets
returned.
I
mean
I,
I
wonder
how
how
much
some
of
these
could
blow
up
in
terms
of,
like
you
know,
thousands
of
references
causing
like
slowdown
on
registries
but
yeah.
I
think
that's
up
to
registries,
to
figure
out
because
yeah
now
we're
talking
about
a
adding
something
adding
an
index
in
the
registries
that
could
just
grow
unbounded.
A
There
there
is
the
down
the
non-ideal
middle
ground
here,
which
is
you're,
probably
going
to
have
less
than
10
of
these
coming
back,
and
so,
if
you're
saying
say
your
index
on
just
that
on
just
the
reference
descriptor
itself,
then
you
can
do
that
parsing
service.
Out
of
saying
you
know,
I'm
already
pulling
these
manifests
to
include
them
into
the
list
here.
Let
me
just
do
that.
Artifact!
Do
that
annotation
filter
on
the
fly
right,
it's
not
an
ideal
point,
but
it
when
you're
talking
about
less
than
20.
It
might
not
be
that
horrible.
C
A
C
A
A
I
had
a
ascending
or
descending,
basically,
it's
like
sort
whatever
the
field,
and
I
did
include
like
a
comma
separated
list.
If
you
needed
to
get
more
complex,
I
hope
for
the
kinds
of
things
they're
sorting
on
you're
never
going
to
get
more
than
one,
but
just
in
case,
that's
kind
of
where
I
was
going
with
it
only
string
sorts
just
like
all
the
comparison
only
string
comparison.
So
I'm
not
getting
anything
beyond
that
for
right
now,
at
least.
A
C
A
A
tough,
tough
ask,
the
one
thing
I
did
say
is
that
at
least
for
page
nation
it
has
to
come
back
with
some
kind
of
order
that
can
be
paginated.
You
know
you
can
come
back
multiple
pages,
so
you
know
if
you
don't
sort
the
way
the
user
requested.
You
need
to
have
some
kind
of
sort,
so
you
can
do
okay,
page
one
page,
two
page
three,
unless
you
just
return
everything
in
one
response,
but
I
don't
think
we
want
to
let
them
get
the
response
too
large
that
could
potentially
upset
clients
too.
A
We
should
keep
these
indexes
at
our
four-make
limit
that
we
kind
of
agreed
on,
and
so
given
that,
given
that's
a
should,
if
we
come
down
to
this
thing
that
this
is
kind
of
the
response
that
there'll
be
an
annotation
on
top
of
that
index
just
says:
hey,
I
process
your
request
with
these
parameters,
and
this
can
come
back
and
say
you
asked
me
filter
all
these
things.
I
didn't
do
any
of
it.
My
filter
list
is
empty.
My
shortlist
is
empty.
I
didn't
do
anything
for
you
at
all.
B
A
B
It's
just
a
lot
of
so
okay,
so
you
you,
you
save
a
manifest.
You
throw
a
blob
into
a
directory,
I'm
just
trying
to
think
of
it
from
the
flow
of
how
registry.
Now
you
say
when
you
do
that,
you
make
a
back
reference
that
says:
hey
this.
B
This
digest
here
is
now
associated
with
this
as
reference
or
you
go
to
what
it's
referencing
and
then
you
create
a
reference
by
or
something
record
in
the
directory.
I'm
I'm
thinking
about
how
like
distribution,
distribution,
might
work
right
and
now
I
come
in-
and
I
say,
hey
give
me
references
which
references
is
almost
referenced
by.
B
A
B
A
B
A
You
could
just
you
could,
in
addition
to
storing
your
this,
this
object
references,
the
other,
you
store
the
entire
descriptor
and
not
just
a
small
pointer,
and
so
you
could
package
this
entire
descriptor
up
right
here.
I'm
saying
here
is
one
of
them
and
then
you
just
have
a
whole
collection
of
them.
A
And
this
is,
you
know
even
this
api,
it
is
a
should
well,
it
exists,
and
there
is
the
comment
here
that
you
know
hey.
If
it
doesn't
exist,
it
doesn't
work,
just
give
us
a
four
or
four,
and
then
we
fall
back
to
the
tags.
B
I
mean
all
the
reads
are
inevitable,
though,
that
this
object
is
gonna
have
to
be
pulled
in.
It's
not
like.
Well
so,
for
example,
the
way
I
think
docker
hub
would
do
it.
Is
you
have
this
backing?
B
You
have
everything
backed
by
s3
right
and
when
you
actually
go
to
fetch
data,
it
doesn't
return
the
data
directly.
It
always
returns
a
simile,
that's
going
to
go
through
cloud
front
or
something
to
actually
access
the
data
in
s3.
A
B
Not
sure
about
all
the
manifest
I
don't
remember
yeah
I
mean
you
could
look
at
yeah
how
the
cloudfront
middleware
is
insulated
and
distribution.
A
However,
your
story,
I'm
associated
with
that
or
you
can
go
a
layer
below
and
say.
Okay,
let
me
store
this
to
me
type,
this.
The
sizes
digest
here
all
the
annotations
and
then
just
rebuild
this
every
time
I
I
can
see
someone
saying
yeah,
we
don't
want
to
rebuild
every
time
just
for
performance,
but
at
the
same
time
storage
and
be
able
to
parse
it
apart.
B
I
mean
it
depends
what
type
of
back-end
you're
using
like
a
lot
of
the
back
ends,
are
kind
of
eventually
consistent
in
nature
right,
so
like
rebuilding
it.
Every
time
would
be
a
completely
different
model
like
if
you're
have
a
consistent
database,
then
sure
rebuild
it.
But
that's
that's
expensive,
where
you
can
have
a
background
process
that
goes
and
rebuilds
it
as
well.
B
A
We've
got
this
part
right
now
on
the
image
manifest
that
I
think
we
could
probably
start
working
on
a
pr
for
this
one,
and
then
I
don't
know
at
all
where
pr
belongs,
but
I
think
we
can
probably
come
up
with
a
relatively
quick
agreement
on
this.
What
a
digest
tag
is
going
to
look
like
that's
the
format
and
then
hopefully
find
a
place.
A
If
we
do
those
two
things,
we've
got
a
solution
that
people
can
use
today.
No
changes
to
a
registry
other
than
I
think
we'll
have
to
make
sure
aws
is
on
the
page
with
us.
I
don't
mean
to
single
you
guys
out,
but
just
making
sure
that
we're
not
hitting
any
of
the
media
type
filters
that
happen
on
over
there,
and
so
with
those
two
things.
B
A
So
this
is
always
like
what
we're
throwing
out
there
now
with
the
digest
tag
stuff
like
that.
That's
always
been
kind
of
thought
process
of
it's
good
enough
to
start
with,
but
we
want.
We
want
to
be
somewhere
better.
Everybody
wants
to
have
this
api
in
there
in
the
registry
and
then
once
we
have
the
api,
we
know
we've
already
got
the
new
media
type,
hopefully
got
approved
at
the
same
time.
So
hopefully
we'll
get
registries
update
with
everything.
A
At
some
point,
I
think
where
I'm
going
with
the
breathing
room
is,
we
might
want
to
take
a
step
in
this
one
and
say:
let's
actually
implement
this
in
distribution
distribution
and
see
what
it
looks
like
over
there
and
see
if
we're
breaking
anything,
and
so
it
may
take
us
some
time
to
get
that
implementation
put
together,
but
we
can
still
make
progress
in
getting
the
community
a
starting
point
on
their
side.
While
we're
sorting
that
out.
B
A
Go
back
sorry
for
scrolling
on
a
video
call,
but
best
we
can
do
here.
Do
you
think
that
we
would
have
to
change
this
reference
field
in
some
way
or
have
we
kind
of
gone
back
and
forth
on
that
one,
not
just
on
this
proposal
here?
But
you
know
this
was
came
out
proposal
b,
which
had
been
discussed
way
back
when
what's
what's
the
associated.
A
A
A
These
are
the
config,
but
we're
doing
make
sure
I
get
the
right
tab
here.
Of
course,
I
don't
that
would
be
the
config
media
type
inside
the
config
blob.
This
is
going
to
be
on
the
image
manifest,
so
we're
just
changing
the
image
spec
and
nothing
else.
A
C
C
A
C
C
Guess
I
think
partially,
as
I'm
approaching
it
from,
I,
don't
love
the
idea
of
implementing
the
ability
like
implementing
arbitrary
sword
and
filter
on
any
annotation,
and
if
we
pulled
some
of
these
important
fields
out
of
the
annotations
blob
and
into
you
know
top
level
fields
on
the
manifest
or
somewhere
else
where
they
are
clearly
special.
C
A
If
we
did
that,
if
we
pulled
up
artifact
type
into
its
own
thing,
would
you
then
say:
okay,
you
know
users
can
put
whatever
other
artifacts
they
or
annotations.
Sorry,
whatever
other
annotations
they
want
to
on
their
artifact.
But
when
we
build
this
list
here
were,
are
we
going
to
still
do
this?
Are
we
still
going
to
pull
it
up
and
give
the
user
all
the
annotations?
Are
we
going
to
say
no
we're
just
giving
you
a
minimal
descriptor
here?
C
Yeah,
I
I
think
you
could
still
do
you
could
still
return
the
annotations
or
you
could
return
a
data
field
that
has
to
manifest
entirely
the
the
thing
I
think
about
when
we
are
returning
the
annotations
is
the
annotations,
isn't
really
bounded,
and
so
potentially
you
are
returning.
A
Yeah
the
the
hesitation
I
have
for
the
data
field
as
much
as
I
love
it,
and
I'm
doing
it
for
other
stuff
already.
It's
just
thinking
that
okay,
the
client's
going
to
parse
that
apart,
which
that's
not
too
difficult,
but
are
we
adding
in
for
the
average
use
case,
a
lot
more
overhead
that
registries
don't
want
to
include,
because
the
average
use
case
is
going
to
be
there's
probably
only
a
handful
of
annotations.
C
A
B
Yeah
I
mean
where
the
where
the
signing
validation
happens.
I
mean,
I
think,
that's
something
that's
you
know
for
discussion
for
a
while.
Is
that
an
open
policy
is
that
something
that
we
should
do
in
the
container
run
time?
I
know
that
there's
some
desire
to
have
it
done
in
the
container
run
time,
but
it's
yeah
it's
it's
the
place
that
we
also
want
to
be
the
fastest.
B
I
feel
like
slowness
and-
and
I
think,
kubernetes
layers
kind
of
expected,
but
we
always
try
to
be
as
fast
as
possible.
We
actually
start
things
up.
We
just
start
off
with
a
with
a
digest.
B
Validated
it's
pretty
fast,
but
if
you
want
to
put
your
policies
actually,
next
to
your
runtime,
then
yeah
there's
there's
a
lot
of
extra
fetches
that
need
to
happen
here
that
can
slow
it
down.
C
B
Yeah-
and
I
guess
there's
there's
also
potential
here
in
the
run
time-
I
think
possibly
do
it
in
parallel
to
the
poll
where
basically
we
can,
we
can
get
started
on
the
process
and
validate
it
while
we're
doing
the
unpack
there's
not
too
much,
I
mean
the
the
worst
case
scenario.
Is
we
wasted
wasted
that
effort,
but
we
can
still
parallelize
the
process
and
throw
it
away
at
the
end,
like
the
idea
that
you
know
we
might
pull
some
malicious
content
briefly
and
then
throw
it
away.
I
think
it's
less
of
a
concern.
A
B
I
mean,
I
think
one
hop
is
fine
like
if,
if
the
result
in
this
index,
I
can
just
look
at
it
and
be
like
oh,
this
is
what
I
care
about.
I'm
going
to
go
fetch
those
to
validate,
but
if
what
we're
looking
at
here
is
like
okay,
we're
gonna
first
do
the
filter.
The
filter
may
be
slow
because
on
the
server
side,
even
doing
a
bunch
of
stuff
read
this
figure
out
my
own
local
filters.
What
do
I
actually
want
to
use
now?
B
B
B
Not
talking
about
large
data
like
the
blobs
for
layers
can
be
large
like
embedding
them
doesn't
make
sense,
but
for
stuff
like
signatures,
it's
nice,
like
signatures,
are
small
enough
to
just
put
in
an
annotation
in
the
first
place.
You
know
here,
you
know
you
can
put
them
as
a
blob.
B
B
Yeah,
I
mean
that's:
clients
need
to
set
some
limit,
though,
like
I
think
in
continuity,
we
do
set
it
to
four
megabytes.
Just
because,
like
at
some
point,
we
have
to
say
hey.
This
is
too
much
like.
You
can't
just
send
unlimited
amount
of
data
back
to
the
client
to
process,
especially
if
it's
going
to
go
through
jason's
person.
A
Well,
that's
the
next
action
item.
That's
awesome!
I
was
wondering
if
we
were
going
to
go
other
stuff
even
before
we
get
approved
well.
These
are
just
proposals.
B
A
B
A
Well,
there
is
a
possibility
that
we
can
say:
okay,
we've
got
proposally.
Let's
do
propose
a
left
that
looks
at
maybe
something
other
than
this
index
syntax.
Maybe
we
do
the
data
field.
Maybe
we
change
the
filters?
Maybe
we
pull
up
just
the
artifact
type
in
a
couple
of
fields,
I'm
comfortable
the
group
says:
hey
we.
We
need
a
little
bit
more
time
on
those
things
and
to
sort
that
out.
A
My
own
thought
process
is
I'd
like
to
go
through
and
look
at
of
course,
I'm
doing
hand
motions
without
even
having
my
video
on
my
personal
goal
is:
let's
get
the
stuff
out
there
today
that
people
need
to
standardize
on
stuff
that
they're
kind
of
already
doing
already
and
just
get
that
document
so
that
people
can
at
least
the
stuff
they're
doing
today
they
can
do
it
the
same
way
as
all
the
other
people
they're
doing
today
and
then
get
this
stuff
tested
within
distribution
spec
to
make
sure
that
we
aren't
breaking
anything
over
here
with
some
of
these
others
with
like
the
api.
A
C
Guess
it
feels
like
most,
I
think
most
users
will
want
to
filter
by
artifact
type
and
then
maybe
sort,
I
think,
sort
by
time
by
like
the
created
time.
But
you
know
maybe
there's
maybe
there's
others
that
we
should
be
considering
too,
and
I
think
saying
we
want
to
do
this
solution
means
that
it
will
be.
C
A
C
A
A
And
I'm
I'm
hesitant
to
put
in
there
saying
okay
here
is
us
pulling
up
the
signer
field
into
the
top
level,
because
people
are
going
to
want
to
filter
on
that
for
signatures,
but
that's
not
going
to
have
a
whole
lot
of
value
for
people
generating
an
s
bomb
because
the
s
ball
might
not
be
signed
within
that
or
in
fact
it
might
be
another
artifact.
On
top
of
the
s
that
provides
a
signature.
A
B
Yeah,
I
I
approved
it.
I
think
I
think
yeah.
I
think
the
final
version
might
go
through
some
iteration,
maybe
even
having
some
common
pattern,
because
yeah
realistically,
it
might
be
that
most
of
requests
end
up.
Looking
the
same,
anyways
and
registries
want
to
cash
on
that
or
something
you
know
like
yeah.
B
You
talked
about
like
there's
that
there's
that
common
case
that
I
say
most
clients
are
just
gonna
are
going
to
just
put
together
the
same
exact
requests,
same
exact
set
of
filters
and
then
there's
that,
like
that,
that's
going
to
cover
like
99,
and
this
would
be
the
small
one
tail
of
oh,
I
want
to
sort
on
these
this
field
in
this
field,
and
you
know,
for
the
most
part,
the
clients
will
just
want.
The
latest
latest
signature
latest
scan.
B
You
know
latest
s
bomb
whatever
you
know
and
it'll
make
more
sense
for
registries
to
just
gc
stale
content
rather
than
to
focus
on
you
know.
How
do
I
sort
all
this
stuff
out.
B
Mean
the
thing
is,
we
don't
need
to
be
prescriptive
about
it?
I
understand
from
from
the
registry's
perspective,
if
usually
users
are
just
saying,
hey
just
just
give
me
what's
relevant,
you
know,
don't
give
me
a
bunch
of
old
stuff
and
that
the
registries
can
pretty
much
determine
what's
relevant
like
if
you
have.
You
said
a
bunch
of
like
daily
scans
of
something
you
probably
don't
care
about
anything,
except
for
the
most
recent
scan.
A
So
let
me
ask
you
this:
we've
got
a
handful
of
them
defined
up
here.
The
work
open
containers,
our
effect
type
description,
created.
A
What
if
we
said
that
some
registries
are
going
to
say,
they're
only
going
to
filter
on
these
for
you,
and
that
gives
you
the
ability
to
say,
hey,
we're
going
to
go
up
there,
we're
going
to
index
these
annotations
out
from
the
from
whatever
you
give
us
and
put
that
in
registry
or
in
our
database,
and
then,
when
the
query
comes
in.
If
someone
queries
on
just
those
fields,
they'll
get
back
in
that
little
annotation
at
the
end
that
says:
hey.
A
B
But
what
I'm
saying
is
like
okay,
what
I?
What
I
probably
care
about
is
is
a
much
more
complex
query
than
that
right.
You
said,
sort
on
creating
and
these
specific
types,
but
it's
like
well,
I
want
the
latest
signature.
I
want
the
latest
s.
Foam,
maybe
that's
it!
I
just
want
those
two,
but
it
could
be
that
you
have
a
process.
That's
coming
in
it's
creating
a
signature
every
day
and
say
you
created
an
s
bomb
once
when
when
the
artifact
was
created.
B
A
I
think
those
are
going
to
be
multiple
requests,
though
I
think
you're
going
to
have
one
request.
That's
going
to
come
in
and
say
give
me
the
signatures,
and
the
second
request
is
going
to
come
in
and
say,
give
me
the
desk.
I
don't
think
we're
going
to
get
both
of
those
in
the
same
request.
Unless
someone
just
says
give
me
every
artifact,
every
reference.
A
A
On
the
same
field,
it's
going
to
say
well,
there's
nothing
that
equals
both
s
bomb
and
signature,
because
those
are
mutually
exclusive.
So
there's
only
you
can
only
pass
one
filter
parameter.
You
can
pass
multiple
filters.
This
is
going
to
be
like
you
can
multiple
parameters
you
just
keep
going
through
all
of
them,
but
any
response
to
your
filters
has
to
match
all
the
filters.
A
Be
tricky
because
the
goal
here
is
to
say
that
if
you
don't
support
one
of
the
filters
or
any
of
the
filters,
the
user
just
gets
back
more
data
yeah.
It's
not
that
we're
corrupting
that
kind
of
complex
query.
It's
just
you
just
get
more
data
back
and
now
the
client
has
to
filtering
out
yeah.
I
think
maybe
the
filters
will
almost
be
better
off.
B
Like
being
broken
out
to
just
say,
type
equals
something,
and
then
you
can
specify
and
support
annotation
filters
if
you
want
anyways
yeah.
This
is
the
type
of
thing
where
I
I
feel
like.
Once
you
actually
start
to
code
it
it's
either
going
to
make
sense
or
not
make
sense
or
it's
a
is
it.
A
A
This
was
also
the
area
I
got
to
when
I
was
thinking
of.
Do
I
start
having
those
special
fields
like
artifact
type
and
whatnot?
Well
now
I
have
to
put
other
query
parameters
on
here.
If
I
can't
filtering
for
an
annotation
and
then
I'm
filtering
for
the
artifact
type,
I
can
see
it's
getting
a
lot
more
complicated
enough.
I
just
said
okay,
I.
B
A
Yeah
all
right!
Well,
I
used
your
whole
hour
up.
I'm
not
sure
if
you
have
another
meme
come
up
after
this,
but
if
you
do
feel
free
to
jump-
and
this
was
super
productive
for
me.