►
From YouTube: [OCI-WG] Reference Types - 2022-03-29
B
C
B
I
think
we're
coming
up
on
five
after
so
here
I
don't
know
if
we
normally
do
the
initial
kickoff
stuff
saying
it's
a
recorded
call
and
under
the
lengths
foundation
code
of
conduct,
all
that
good
stuff,
so
be
awesome
to
each
other.
That's
that's
the
way
I
like
to
say
it.
Some
people
say
you
know,
don't
say
anything.
You
wouldn't
normally
say
in
a
recorded
call,
but
just
be
awesome
to
each
other
misha.
I
think
you're
up.
First
with
the
proposal
c
rubric.
D
It's
not
much.
It's
just
a
announcement
that
it's
available
for
review.
D
You
know
I
I
would
rather
address
the
second
agenda
item
that
you
have
over
there,
which
is
how
do
we
consolidate
all
the
reviews
on
each
of
the
rubric?
Because
if
you
look
at
the
rubric
that
I
have
posted,
it's
just
a
bunch
of
yeses
and
no's
and
one
not
applicable,
but
it
doesn't
give
anyone
any
more
information
than
that
josh
is
not
here
yeah.
I
was
going.
B
To
stall
for
just
long
enough
until
he
could
show
up
hoping
that,
maybe
he
would
show
the
the
main
thing
that
I
took
out
of
the
last
discussion
on
this
one
was
that
josh
and
I
kind
of
had
different
points
of
view
of
where
we
were
coming
from,
where
he
was
looking
to
make
the
proposals
just
a
simple
proposal,
nothing
else
in
there
and
then
have
the
rubric
discussions,
maybe
a
separate
file
per
proposal.
Then
we
could
put
each
of
those
and
I
was
coming
at
it
saying
to
me.
B
It
feels
like
it's
nicer
to
have
everything
as
a
single
document
that
anybody
that
coming
into
this
that
doesn't
know
anything
about
any
of
this
stuff
and
just
look
at
a
proposal
and
see
all
the
way
through
here's.
What
they're
proposing
here's,
how
it
solves
different
issues,
here's
the
challenges
they
may
have
and
I
have
to
bounce
around
between
different
places.
B
B
D
So
I
I
liked
your
first
the
way
you
did
it,
which
was
you,
you
submitted
the
rubric
document
and
then
you
had
at
the
bottom
a
list
of
like
explanations
as
to
why
you
rated
it
that
way,
and
so
I'm
wondering
if
it
makes
sense
to
add
you
know,
comments
and
then
proposal
a
proposal
b,
proposal,
c
proposal
d,
and
so
we
basically
update
the
rubric
and
add
the
comments
at
the
bottom.
B
B
Okay,
so
what
we
were
talking
about
here
was
when
I
filled
it
out,
and
this
is
nothing
I
want
to
chat
about.
You
know
it
said
yes,
no,
but
also,
maybe
so
in
a
couple
different
places
and
then
at
the
bottom.
I
had
a
couple
notes
in
there
that
that
is
a
way
I
feel
like
some
of
the
pushback
I
got
from
the
discussion
was
that
it
wasn't
quite
enough,
and
so
people
wanted
to
see
more
detail
than
just
this.
They
wanted
to
see.
Why
is
c12
a
yes
and
not?
You
know.
B
B
That
no
it's,
I
wasn't
sure
if
it
was
hiding
that
I
was,
I
had
something
up
over
the
screen
there,
so
I
wasn't
sure
if
we
wanted
to
do
this
all
in
the
rubric
thing,
it
does
make
it
a
little
bit
more
challenging,
especially,
I
think
we're
going
to
see
with
yourself
and
myself
nisha
proposal
c.
Has
this
whole
thing
in
this
second
column?
So
whenever
we
merge
one
of
these,
the
other
one's
gonna
have
to
be
completely
rewritten
to
do
a
merge
conflict
on
every
single
line.
E
I
might
suggest
we
just
do
individual
rubrics
and
kind
of
do
discussions
and
then,
when
we
finish
the
discussion
each
rubric,
then
we
merge
it
into
the
master
for
evaluation.
C
E
C
E
B
And
I'm
trying
to
be
good
whenever
I
add
a
new
entry
in
there
to
make
sure
that
we
add
it
to
the
end.
Some
people
might
have
seen
that
I
just
went
in
there
and
merged
in
it
was
our
requirements
just
merged
in
the
yeah
backwards?
Seven.
So
there
is
now
a
b7
in
the
list
that
wasn't
there
a
minute
ago.
So
I'm
trying
to
be
good
at
least
saying.
Let
me
add
the
number
to
the
end
and
not
to
the
middle.
B
I
think
through
some
of
those
challenges,
but
there
may
be
a
few
of
these
cases.
We
have
to
go
back
through
all
the
other
implementations
and
say:
okay,
oh
we
just
added
b7.
Now
we
need
to
go
through
everybody
that
copy
this
stuff
into
their
own
place
and
update
their
rubric
reference.
On
top
of
this.
B
B
Do
we
want
to
have
within
proposal
d
at
the
bottom,
just
saying:
here's
how
this
solves
all
the
different
parts
of
the
requirements
and
just
have
a
list
down
here
of
you
know
the
different
filter,
one
two,
three
four,
the
backward
and
those
different
things.
Does
it
make
sense
to
append
to
this
document
here,
and
so
we
could
just
extend
whatever
our
proposal.
Format
is
to
include
how
to
use
all
the
different
challenges
we
have.
That's
a
and
b
is
just
to
say
to
make
a
different
folder
over
here.
B
Keep
the
proposals
minimal,
but
make
a
different
proposal
every
different
folder
over
here.
That
just
says
requirements
for
a
b
c
and
d
and
have
people
look
at
a
second
place.
I
think
that's
where
josh
and
I
were
back
and
forth
on
each
side
of
it.
I
don't
think
either
of
us
do
picking
on
either
one.
So
that's
where
I'm
just
turned
it
back
over
to
the
community.
It's
saying:
should
it
all
go
on
proposals,
or
should
we
make
a
different
order
and
do
it
the
other
way.
A
B
Yeah,
I
I'm
in
the
same
category.
You
are
jason
as
long
as
we
can
get
this
moving
forward.
Let's
see
nisha
thoughts.
There.
E
B
Just
wanted
to
keep
proposals
as
a
minimal
it
came
in
as
here
is
what
I'm
doing
he
didn't.
I
don't
think
he
wanted
to
modify
it.
He
just
wanted
to
be
a
static
thing.
It
just
came
in
as
a
minimal
thing
of
here's.
What
I'm
proposing
nothing
else!
You
can
look
at
this
and
understand,
but
that
was
his
reasoning.
I
had
different
reasoning.
I
might
not
be
the
best
to
explain
his
reasoning.
B
I
think
it
was
and,
of
course
I
put
myself
as
a
notetaker-
I'm
not
taking
any
notes
here
today.
So
if
anyone
else
is
being
good
and
feels
like
jumping
and
go
for
it,
but
yeah,
I
believe
it
was
last
might
have
been
one
before.
B
Okay,
everyone
that
want
to
get
an
opinion
in
feels
like
you've
gotten
your
opinion
in.
I
think
that
was
the
entire
point
on
sorting
out
where
we
put
this
stuff.
B
So
as
long
as
we're
going
to
put
it
here,
we
might
want
to
update
the
template,
and
so
I
can
put
a
little
pull
request
onto
that
one,
just
kind
of
add
a
section
down
below
of
here's,
how
we
solve
each
of
the
requirements
and
so
template
updated.
And
then
we
just
need
to
go
through
the
proposals
and
add,
in
a
section
the
bottom
of
each
one
of
these
of
saying:
here's
how
a
b
c
and
d
solves
each
of
these
requirements
make
sense
to
everybody.
B
Cool
and
then
the
thought
process
I
had
is,
since
we
put
him
in
the
proposal,
we'll
finish,
that
up
get
all
the
back
and
forth
question
answers
solved
within
the
proposal
section
itself
and
then
once
we
have
the
yes,
no,
maybe
just
copy
that
one
bit
from
each
of
these
proposals
into
the
rubric
at
the
end,
which
just
references
saying
if
you
want
to
know
why
we
said
yes,
go.
Look
at
this
section
of
this
proposal.
E
Let
me
raise
the
discussion
of
client
versus
server
differentiation,
because
I
I
was
watching.
I
was
reviewing
a
couple
of
them
and
I
saw
that
you
know
there
was
a
boolean
of
yes
with
to
your
point,
no
details,
and
then
there
was
even
I
think
filtering
six
was
I.
I
didn't
read
that
as
even
a
question,
but
we'll
come
back
to
that
one
for
a
second,
but
I
just
I
saw
a
bunch
of
these
like.
E
I
think
there
is
a
difference
whether
it
can
be
done
service
out
on
client,
because
on
a
client
you
can
download
the
entire
registry.
At
a
certain
point,
you
say:
that's
not
practical,
as
we've
been
going
through
having
lots
of
scan
results
associated
with
an
artifact
with
an
image,
we've
started
to
think
more
about
the
quantity
of
things
that
get
returned.
E
So
it's
I'm
and
if
you
have
to
round
trip
because
the
details
are
not
in
the
descriptor
they're
in
the
manifest.
So
now,
if
you
could
return,
I
think
we're
all
focusing
on
returning
a
list
of
descriptors
in
the
referrers
api
as
an
example
and
there's
not
enough
in
there
to
actually
do
any
filtering.
So
now
you
have
to
pull
the
entire
manifest
down.
So
I'm
just.
I
think
those
are
good
things
to
clarify.
E
E
B
Yeah,
that
was
where,
in
some
of
the
stuff
that
I'd
put
at
least
for
proposal
d,
I
think
I
was
being
specific
to
say
that
it
was
possible,
but
it
was.
It
was
going
to
require
the
client
to
pull
back
each
of
those
artifacts
and
filter
the
client
side,
and
so
it
was
not
optimal,
and
I
wouldn't
want
to
say
yes,
unless
we
have
something
that's
going
to
scale.
A
Jason,
oh,
I
was
just
going
to
say
I
think
it's
I
think
it's
worth
to
steve's
point.
I
think
it's
worth
calling
out
how
much
work
the
client
has
to
do
to
filter
and
if
it's
not
filterable
in
the
descriptor,
we
can
put
it
in
it.
Put
enough
information
in
the
descriptor
to
make
it
filterable
you
shouldn't
have
to
parse,
you
shouldn't
have
to
fetch
and
parse
10
000
scan
results
to
be
able
to
make
sense
of
the
one
you
care
about.
E
E
How
do
I
make
sure
I
get
the
newest
right
there's
a
couple
of
details
in
there
that
either
you
need
a
listing
wall
and,
depending
on
what
information
gets
returned,
you
might
have
to
go
another
request
deeper
and
then
on
the
ordering
is
an
interesting
one,
because
we
went
through
this
a
bit
in
the
promotion
scenarios.
The
registry
doesn't
know
when
it
was
initially
created.
It
just
knows
when
it
was
sent
to
it.
E
So
a
scan
date
is
an
interesting
question,
especially
if
you're
trying
to
do
it
in
a
generic
way
like
yeah.
How
aqua
does
scans
might
have
a
different
schema
than
how
qualis
or
twist
lock
whatever
twist
lock,
is
named
today.
A
Yeah,
I
mean,
I
think,
filtering
by
type,
should
definitely
be
handled
by
the
descriptor
having
a
type
or
the
descriptor
having
an
annotation
describing
whether
it's
scan
product
a
or
scan
product
b
same
for
newest,
if
newest,
is
a
thing
that
matters
or
the
date
of
the
thing
is
a
thing
that
matters,
then
that
should
be
in
an
annotation.
You
can
scan
that.
B
But
I
think
to
steve's
point
here
when
we're
looking
at
the
backward
compatible
solution,
I've
posed
a
while
back
the
the
tag
that
we
have.
There
has
a
type
on
it,
but
when
you
do
a
tag
ls,
that's
all
you
know,
and
you
have
to
pull
down
at
least
the
manifest
for
the
artifact
to
get
any
of
the
other
annotations
on
there.
A
Yeah
there's
actually
yeah.
There
will
be
a
few
different
types
of
the
client
having
to
pull
something
like
the
client
will
have
to
pull
this
to
get
the
manifest
to
tell
whether
it's
a
spd-xs
bomb
or
a
cyclone
dxs
bomb
or
a
jason's
s
bomb
or
whatever.
But
it
doesn't
have
to
fetch
the
whole
s-bomb
object,
which
is
presumably
much
bigger
than
the
manifest
to
be
able
to
parts
to
tell
whether
it's
a
what
type
of
s-bomb
it
is
or
whatever.
A
I
guess
my
point
was:
you
may
end
up
in
a
situation
where
filtering
requires
you
to
pull
hundreds
of
manifests
manifest
being
you
know
about
a
k
of
text
easily
parsable
by
json
and
not
you
know,
potentially
kilobytes
megabytes
of
scan
results
that
you
have
to
parse
through
and
earth
fetch
first
and
parse
through
or
whatever.
I
don't
think
any
of
the
proposals
require
fully
fetching
the
entire
s
bomb
to
be
able
to
tell
whether
it's
type,
a
or
type
bs
bomb.
B
E
B
Yeah
hard
agree
on
that,
one
that
I'd
like
to
definitely
see
it
within
whatever
we
specify
on
our.
However,
we're
answering
the
requirements,
I'm
hesitating
say
rubrik,
because
that's
more
the
graph
thing.
I
think
we
should
specify
this
down
below
within
our
proposal.
B
D
Efficiency
or
like
equal
sharing
of
server
side
or
client-side
thing,
or
is
that
not
something
that
we're
considering
we
we
seem
to
be
having?
We
seem
to
be
moving
that
way,
saying
like
yes,
okay,
theoretically,
it
can
happen.
We
can
do
this,
but
we
can't
really
say
whether
we,
whether
it's
scalable
or
not,.
E
I
think,
like
that's
it's
funny,
because
I
went
back
and
it
reads
user
stories
like
okay
from
a
user's
perspective.
What
do
they
care
like?
Well,
if
the
user
is
waiting
forever,
because
it
does
take
a
long
time?
That's
a
a
good
way
of
saying
a
user
story.
I
mean
the
reality.
Is
these
registries
have
had
most
many
of
them?
E
Certainly,
you
know
the
cloud
ones
that
you
know
as
opposed
to
the
individual
standalone
ones,
that
people
set
up
in
their
clusters
have
petabytes
of
data
so
having
efficient
apis,
so
that,
as
the
hundreds
of
thousands
of
users
that
are
hitting
them
are
not
asking
them
for
tons
of
data
is
a
scalable
thing
from
an
implementation
and
from
a
user
from
how
long
it
takes
for
them
to
get
the
data
and
honestly
an
egress,
because
clouds
charge
egress
network
egress.
So
for
all
of
us
working
at
home,
it
does
add
up.
B
Well,
not
just
the
network
egress,
but
I'm
also
thinking
to
docker
hub
and
how
they've
implemented
their
rate
limits.
Their
rate
is
per
manifest
poll,
and
so,
if
you
have
a
hundred
annotations
or
a
hundred
artifacts
attached
to
your
image
and
you
have
to
pull
each
one
of
those
you're
going
to
blow
your
entire
rate
limit,
just
pulling
a
single
image.
E
And
it-
and
I
just
I'll,
tie
that
back
docker
implemented
something
because
there's
a
high
cost
associated
with
it,
like
I
wouldn't
make
it
a
fault
of
docker
dockers,
dealing
with
the
fact
there's
high
volumes
associated
with
it
is
that's
how
they
implemented.
I
mean
salesforce
did
this
years
ago
with
how
they
do
their
rate
limits
on
their
apis
too.
It's
not
meant
to
generate
revenue,
it's
meant
to
drive
good
development
practices,
yeah
it's
for
the
same
list
of
states
four
times
on
a
single
page.
B
Yeah
I
mean
I'm
over
in
the
captain's
program:
I'm
not
faulting
docker
for
what
they
did.
They
need
to
find
something
to
make
it
maintainable,
I'm
just
thinking
of
what
we
do
and
how
that
impacts,
how
other
users,
or
how
other
registries
have
implemented
their
solutions
and
what
issues
we
could
come
into
depending
on
how
we
implement
our
solution.
D
B
D
A
A
I
think
in
general,
where
possible
so
proposal,
d,
no
changes
is
necessarily
making
no
changes
to
the
api,
and
so
the
registry
can't
make.
I
think,
steve
made
this
point.
The
registry
didn't
know
that
it
might
eventually
need
filtering,
so
it
won't
be
able
to
filter,
but
on
the
other
ones.
I
think
we
should
try
to
bias
towards
at
least
describing
how
filtering
should
be
implemented.
If
you
are
interested
in
implementing
filtering
as
a
registry.
E
The
logic
kind
of
goes
if
you're
gonna
make
like
if
there's
zero
changes.
That's
zero.
Zero
is
finite.
If
you're
going
to
ask
a
registry
to
make
changes,
make
let's
make
the
changes,
be
healthy
for
the
registry
healthy
for
the
user
healthy
for
the
everybody
like
once
you're
past
zero,
there's
a
lot
more
doors
open.
B
So
we
got
the
decision
that
we
want
to
add
to
the
end
of
these
proposals
here
nisha.
Would
you
like
to
go
through
and
dig
into
proposal
c,
otherwise,
I'm
just
trying
to
think
of
like
best
use
of
our
time
here.
The
other
thought
I
have
is
thinking
through
logically
how
some
of
these
things
could
be
collect
it
together
as
a
set
instead
of
saying
we're
just
going
to
do
just
one
proposal
how
these
things
can
be
merged
into
some
kind
of
hierarchical
rollout
plan.
A
I
think
rate
limiting
is
related
to
gc
in
terms
of
it's
not
really
specified
by
oci
at
all.
We
can
make
informed
decisions
based
on
what
real
world
registries
do
today.
As
far
as
I
mean
the
same
with
garbage
collection
and
rate
limiting,
but
we
shouldn't
assume
or
require,
or
even
should
rate
limiting
in
any.
A
Like
I
mean
we
should
design
the
we
should
design
the
solution
so
that
it
doesn't
make
rate
limiting
worse
or
hit
existing
rate
limiting
semantics
quicker
than
necessary.
A
E
Yeah,
I
think
it's
a
tool
just
you
have
to
think
about
rate,
limiting,
isn't
the
problem
right.
Limiting
is
a
tool
to
make
requests
more
efficient.
This
guy
was
using
the
salesforce
example
like
salesforce,
like
they
make
limits
on
their
api
requests,
and
they
you
can
buy
more
if
you
really
need
them,
but
that's
not
their
intent.
Their
intent
is,
please
write
good
code.
Don't
ask
me
the
same
question
a
thousand
times
over.
Please
let
implement
apis
that
are
efficient,
so
the
the
clouds
can
operate.
We
can
watch
our
youtube
videos
instead.
D
There
is
a
requirement
at
the
bottom
about
if
you
scroll
down,
there's
a
registry
operator,
I
want
to
provide
users
with
retention
policies,
there's
also
one
about
there's
another
bunch
of
registry
operator,
thingies.
D
B
I
just
wonder
if
it
makes
more
sense
to
be
is
like
a
meta
discussion
on
filtering
of
saying
all
the
filtering
answers.
Ideally
it's
on
server
side
as
a
backup.
It
can
be
done
on
the
client
side
and
then,
if
you
can't
do
it
at
all,
and
you
have
to
actually
pull
blobs
and
that's
not
not
ideal
for
anybody.
E
E
And
what
do
you
need
to
surface
right
like
some
of
this
stuff
isn't
just
like?
Oh,
I
just
need
to
write
a
better
api
on
the
server
it's
like
well
turns
out.
Some
of
these.
You
actually
need
some
data
from
the
user,
so
that
drives
kind
of
requirements
back
like
hey.
If
you
actually
give
us
a
creation
date
in
your
manifest,
then
the
registries
don't
need
to
make
up
guess
when
the
thing
was
created,
they
could
say.
Look
you
already
told
me
when
you
were
created.
E
B
And
there
might
be
a
case
here
where
it
makes
sense
to
say
we
don't
want
the
registry
server
itself
to
do
all
the
work,
because
we
don't
want
to
push
a
lot
of
extra
workload
onto
the
registry
server,
but
the
api
response
back
to
the
client
might
include
enough
data.
The
client
can
do
that
filtering
on
its
side
when
it
sees
a
whole
list
of
things.
There
might
just
be
additional
data
in
the
list.
That
says
here
are
the
annotations
that
are
in
that
descriptor
that
has
returned
back
instead
of
just
giving
you
a
descriptor.
D
Okay,
I'm
I'm
happy
to
leave
it
there.
Do
you
want
me
to
go
through
proposals?
The
proposal
theodore
brick
then.
B
B
B
After
we
finish
our
discussion,
oh
my
goodness,
do
we
need
to
loop
you
back.
In
josh,
we,
we
elected
to
extend
the
the
proposal
format
to
put
how
we're
going
to
solve
the
requirements
at
the
end
of
the
proposals.
F
B
E
There's
still
manual
intervention
to
get
them
posted,
but
yes,
yeah
and
you
have
to
just
because
I
do
this
for
some
of
the
other
ones.
You
have
to
actually
go
to
the
zoom
account
download
the
video
and
upload
it,
so
they
could
be
uploaded
to
another
channel.
It's
just
up
to.
Whoever
has
who's
been
uploading.
The
oci
calls
it
was
access
to
the
oci
zooms
meeting.
F
B
D
Yes
is
it
you
know
what
I'm
going
to
see
if
I
can
make
it
bigger,
does
that
work
for
everyone.
D
Okay,
so
some
discussions
with
regards
to
proposal
c
that
I've
had
with
brandon
and
others
made
me
want
to
summarize
some-
maybe
some
misconceptions
here-
one
of
the
biggest
ones
I
think
I
may
have
addressed
this
before,
but
I
want
to
bring
it
up
again.
D
Is
why
not
use
index
the
index
manifest
if
that
actually
would
be
the
ideal?
The
ideal
solution
for
me,
but
the
reason
I
introduced
another
manifest,
is
to
not
break
runtimes,
which
expect
the
index
manifest
to
only
have
image
manifest.
D
A
D
It's
the
index
manifest
and
they
have
a
list
of
manifests,
but
I
don't
know
I
mean
those
could
be
just
descriptors
to
blobs.
Those
could
be
just
blobs.
Brandon
has
his
hand
up.
B
Yeah,
I
was
going
to
say:
I've
got
a
open
pr
over
to
ping
on
oci
later
on
this
week,
just
to
clarify
if
we
extend
the
manifest
description
with
another
field,
what
it
means
with
our
sensibility
clause,
that
registry
should
ignore
it
or
just
ignore
meat
kind
of
thing,
and
so
hopefully,
that
shouldn't
break
things.
B
B
The
other
part
I
wanted
to
get
into
on
this
is
just
try
to
make
sure
we
get
some
differentiation
between
d
and
c,
because
one
of
the
proposals
in
d
was
to
use
index
and
have
a
point
to
all
the
different
artifacts
in
there
as
well,
and
that
works
good
as
the
originator
doesn't
work
well,
when
you
want
to
extend
something
else
and
so
having
details
in
here
about
using
references.
I
think
that
was
some
good
value
you're
proposing
in
here.
D
So
the
other
I
mean,
like
I
said
it
looks
just
like
the
index
manifest,
except
it
would
accept.
It
adds
a
description
part,
which
is
where
you
put
all
the
information.
You
would
like
the
client
to
know
about
the
artifact,
and
then
there
is
the
reference
part
which
points
to
which
is
a.
I
guess,
a
description
of
what
the
relationship
is.
That's
the
second
bit
over
here
that
I
would
I
want
clarity
over
so
I
wasn't.
I
wasn't
meaning
the
reference
to
be
an
inverse
pointer
for
garbage
collection.
D
B
If
it's
not
the
reverse
pointer
for
garbage
collection,
the
thing
we
have
to
keep
track
of
is
that
you
do
need
to
make
sure
that
each
one
of
these
things
that
we're
pushing
up
there
is
tagged,
and
so
that
that.
D
So
not
necessarily
because
the
third
thing
that
I've
added
over
here
is
that
an
index
manifest
or
the
known
manifest
can
point
to
another
known
manifest.
So
you
can
like,
if
index
had
the
same
ability,
then.
B
E
Steve
go
ahead;
no!
No!
This
is
a
good
say.
I
was
gonna.
Go
back
to
the
index
conversation
around
manifest
versus
blobs.
I
guess
I
already
opened
up
so
I'll
just
finish
up
that,
so
we
did
that
did
come
up
a
couple
months
ago,
my
women
last
year,
it
does
very
closely
say,
manifests.
So
the
assumption
is,
it
is
a
manifest.
E
E
We
were
focused
on
some
stuff
at
the
time
that
we
just
decided
to
enable
it,
and
we
debated
after
the
fact
we
enabled
it
because
we're
just
trying
to
unblock
a
customer
that
should
we
have
and
should
we
have
brought
this
back
to
the
community
and
say
well.
Why
is
build
x
doing
this,
so
it
very
clearly
says
manifests
it
doesn't
say
blobs,
it
doesn't
say
descriptors,
not
all
registries
support
buildex
doing
that
as
an
example,
so,
by
definition
manifest
technically
does
not
support
blobs.
E
It's
just
some
of
the
registries
have
either
didn't
check
or
opened
it
up,
but
I
do
think
it's
something
that
if
we
want
to
add,
we
need
to
be
more
diligent
around
that
definition
than
expected
behavior,
because
it
is
definitely
I
don't
even
think
it's
ambivalent.
It's
very
clear.
It
says
manifest
it
doesn't
say
blobs
or
descriptors.
E
So
it's
just
something
that
has
come
up.
D
D
It
also
allows
for
like
an
upgrade
path.
So
if
clients
become
sophisticated
enough
to
be
able
to
say
like
discern
one
type
of
blob
from
another
one
type
of
media
type
or
manifest
from
another,
then
you
you
could
migrate
that
over
to
index
or
manifest
or
blob
easily,
without
like
changing
the
functionality.
D
Right
so
the
last
thing
I
want
to
point
to
is
this
possibility
of
making
long
chains
and
that
could
hinder
performance.
D
One
of
the
one
of
the
benefits
of
being
able
to
have
a
known,
manifest
point
to
another
node
manifest
is
that
you
are
able
to
you're
able
to
create
a
kind
of
ordering
of.
D
You
can
just
push
a
note
manifest
to
the
same
tag
and
have
it
reference
the
older
known,
manifest
digest.
So
you
have
you
have
the
ability
to
say
like
okay,
the
first
known
manifest.
That's
the
latest.
The
second
known,
manifest
is
the
second
latest
third
known
manifest
is
the
third
latest.
D
B
Yeah
jason
beamy,
but
I've
already
taken
myself
off
mute.
So
there
is
the
challenge.
When
you
have
the
index
point
to
another
index,
I
think
we
might
see
some
client
facing
issues
out
there
where
a
client
doesn't
know
what
to
do
when
they
have
an
index
point
to
another
index,
especially
clients
they're.
Just
looking
for
that
platform
string
they're.
If
they
don't
see
the
platform
string,
they
assume
they
don't
have
the
image
they're.
Looking
for
and
the
other
direction
I
was
going
with.
B
That
was
race
conditions,
and
so,
if
you
say
I'm
going
to
update
a
new
version
of
this,
I'm
just
going
to
replace
the
existing
tag.
If
you
do
that
at
the
same
time
as
some
other
process
going
on,
you
might
see
a
race
condition
where
both
of
you
are
updating
that
same
tag
and
you
might
drop
the
others
changes
in
the
process.
D
B
A
I
was
going
to
mention
nisha.
You
mentioned
that
the
registry
could
impose
a
limit
on
the
depth
of
this
chain
and
I
think
there's
something
that
sounds
scary
about
that
which
is
when
it
when
a
registry
is
accepting
a
push
of
an
object.
A
It's
not
getting
pushed
the
entire
chain
is
getting
pushed
to
that
object
and
that
link,
and
so
at
the
time
that
it
pushes
that
it
receives
that
push.
It
has
to
go.
Look
up
what
that
thing
is
looking
what
that
thing
points
to
and
everything
that
that
points
to
up
the
chain,
which
presumably
is
some
sort
of
database
lookup
or
something
I
don't
know
exactly
how
every
registry
works.
A
But
you
can
imagine
it's
like
a
chase
this
chain
with
a
series
of
queries
up
the
up
the
chain,
so
it
needs
to
do
that
on
each
push,
but
it
also
if
you
are
pushing
a
long
chain
you
end
up
pushing.
I
wish
I
could
draw
this
on
a
board,
but
if
you
imagine
that
I'm
trying
to
push
the
alphabet
a
and
then
b
points
to
a
and
then
c
points
to
b
and
d
points
to
c
etcetera,
etcetera
when
it
gets
the
push
for
a
it
says.
A
A
It
looks
up
when
c
points
to
b
it
looks
at
b
and
then
b
points
to
a
and
then
a
basically,
this
turns
into
a
quadratic
operation
very
quickly,
and
maybe
you
solve
that.
You
know
you
could
solve
that
by
saying
it
can
never
be
more
than
three
layers
deep,
like
quadratic
at
three
is
not
all
that
bad.
But
if
the
registry
imposes
a
limit
of
100
deep,
then
querying
that
can
become
very,
very
expensive
very
fast.
So
that's,
even
though
the
registry
could
block
it.
A
D
A
A
Sure
how
it
would
do
it
except
to
do
it
at
each
push,
it
could
do
it
offline.
Presumably,
and
like
have
some
lag
where
it
says
like
you
know,
we
checked
five
minutes
ago
and
you
were
within
the
bounds,
so
you're
allowed
to
add
another
layer,
but
that
has
different
scaling,
different
problems
but
yeah.
I
guess
my
point
is
when
you
push
each
manifest,
if
that
is
that
pushes
in
a
vacuum
that
that
push
doesn't
come
with
any
information
about
the
rest
of
that
chain,.
D
Yeah,
no,
your
point
is
taken
brenda.
B
I
think
you
really
do
want
to
do
it
at
the
push
time,
because,
if
you
validate
after
the
fact
you're
going
to
tell
the
client
everything
is
fine
and
then
five
minutes
later.
No
sorry
that
was
an
invalid
push,
we're
deleting
which
you
what
we
told
you
we
accepted,
and
that's
not
a
good
scenario
for
registries
to
be
in.
So
we
want
to
know
on
the
push
that
it
was
accepted
by
the
registry,
and
that
is
not
going
to
get
rejected.
Five
minutes
later.
B
I
would
question
if
it
might
be
easier
just
to
flatten
that
index
automatically
on
the
client
side,
and
so,
if
you're
going
to
append
to
an
index,
you
should
grab
the
child
of
that
index
as
well
and
just
pull
everything
up
into
a
depth
of
one
tree
into
your
index
list
that
you
create.
So
you
would
never
have
more
than
one
depth
of
items
to
pull.
D
That
would
work,
but
in
in
that
case
I'm
wondering
you
know
how.
D
How
one
would
how
one
would
know
what
the
latest
signature
is,
but
I
guess
we
you
could
say,
like
you
know
the
very
the
first
one
is
the
latest
one.
D
But
in
that
case
there
isn't
any
I
mean
that's
basically
proposal
d,
which
is
just
one
layer.
You
know
one
layer
down,
you
don't
have
you
don't
have
links
to
you,
don't
have
linking
you,
don't
have
references
to
other
index
manifest,
so
you
don't
have
chains,
but
you
can
collect
all
the
references,
make
a
new
index
and
push
that
index.
B
So
something
that
d
did
that,
I
think,
was
valuable.
Was
that
split
this
into
two
separate
categories,
which
was
we
had
the
index?
But
we
only
said
use
that
for
the
originator,
whoever
created
the
image
would
also
be
creating
the
s
bomb
and
the
signature
by
the
original
saying
I
made
this.
They
would
push
all
that
up
as
one
thing
an
index,
but
everybody
else
that
was
going
to
use.
B
This
was
going
to
push
up
a
separate
artifact
that
just
associated
to
that,
whatever
manifest
they're
associating
with
using
a
tag
they
weren't
actually
modifying
the
index
after
the
fact
that
index,
once
it
was
created
by
the
originator,
was
static,
and
so
that
was
valuable
for
them
and
I'm
trying
to
find
that
value
in
years-
and
I
was
looking
at
that
reference
descriptor
you
had
there
saying,
okay,
well,
the
people
are
going
to
extend
it
later
on,
would
push
up
their
own
nerd
object
with
their
own
fields,
with
that
reference
field
as
well,
and
that
was
how
they're
going
to
link
the
two
together,
and
that
was
how
they're
going
to
get
that
efficiency
so
that
we
didn't
have
the
tags.
D
Yeah
well
it
so
it
seems
to
me
that
it's
very
close
to
d,
except
that
that
you
add
the
reference.
I
don't
know
about
the
description,
though,
because
some
of
the
filtering
rubric
that
I've
said
yes
to
was
filtering
based
on
description
and
that
that
is
more
of
a
client-side
processing
than
a
server-side
processing
thing.
E
D
Sorry
in
docs.
Where
are
the
proposals?
E
D
Yeah,
it's
it's
open-ended
because
it
it's
basically
intended
to
stick
whatever
information
about
the
artifact
an
artifact
provider
wants
to
put
in
there.
D
Simply
because
I
don't
know
the
list
of
artifact
types
that
could
possibly
go
in,
there
is
vast,
and
I
know
that
proposal
a
probably
says
you
can
look
at
artifact
type
in
iana,
but
I
mean
I've
I'm
having
these
discussions
in
like
spdx
3.0
and
we've
we've
like
gone
round
and
round
and
round
on
artifact
types
and
it's
it's
complicated.
B
B
They
should
have
a
good
idea
what
clients
are
going
to
want
to
see
in
there
to
do
the
filtering
by
the
client
and
so
they're
going
to
put
in
this
field
something
that
they
think
the
client
will
find
useful
in
the
future
which
might
be.
This
is
the
s
paul
mcrae.
This
is
the
type
of
s
bomb
that
I
put
in
there.
This
is
the
if
this
is
a
scan
result.
This
is
the
date
that
the
scan
was
run
so
that
it
can
look
at
all
those
it's
kind
of
the
from
the
artifact
producer
field.
B
B
I'm
sure
I
still
have
questions
it's
going
to
take
some
more
reading
through
and
thinking
different
cases
here,
because
what
I
really
want
to
pull
out
is
the
value
of
how
this
is
better
than
just
putting
tags
on
things,
and
so
I
want
to.
I
want
to
try
to
pull
out
some
value
from
that
reference
field
that
you
had
there.
B
That's
not
just
you
know,
here's
a
pointer
over
there,
but
it
doesn't
affect
garbage
collection,
and
so
you
still
have
to
tag
things,
I'm
looking
for
something
more
just
so
that
we
can
say
this
is
this
is
better
than
the
backward
compatible
solution,
because
I
I
think
there
is
potential
value
there.
D
So
you
did
bring
up
the
fact
that
the
the
objects
can
just
be
blobs
and
that
allows
for
the
reference
to
be
operationalized.
D
Yeah
and-
and
I
think
that's
I
think,
that's
okay,
but
it
seems
to
me
that,
in
order
to
figure
that
out,
we
need
to
experiment
with
index
to
see
if
you
know
it
can't
already
do
that.
B
So
index
itself
should
be
pointing
to
blobs.
I
think
we're
getting
really
close
to
proposal
a
though
when
we
go
that
direction.
I
see
steve
with
his
hand
up
so
maybe
he's
thinking
along
those
lines
too
steve
go
ahead.
E
E
That
instant
simplifies
a
lot
of
things
right.
So
now
I
can
start
doing
server
side
filtering.
I
can
start
making
sense
of
some
of
the
annotations
or
the
media
types
and
or
not
so
much
media
types,
the
the
way
we
do
auras
art,
so
we
do
oci
artifacts
is
we
use
the
manifest
config.media
type?
That
was
the
agreement
we
did
at
the
time
that
effectively
is
the
artifact
type
on
the
existing
registries
in
the
aura
stuff.
E
We
just
surfaced
that
as
a
separate
property
to
free
that
up,
so
you
can
start
doing
some
of
those
filtering.
That's
the
major
difference.
I've
seen
between
c
and
d,
the
question
around
blobs
and
descriptors
and
so
forth.
That's
that's
a
whole
another
conversation
we
should
probably
open
up
for
next
week.
C
You
get
the
final
word.
Thank
you
for
explaining
everything
to
me.
B
Stop
shane
awesome
thanks
thanks
for
going
through
that
nisha
and
I'm
sure
we'll
have
a
lot
more
back
and
forth
on
that
one.
So
with
that
until
next
week,
we'll
get
some
more
stuff
for
the
rubrics
put
together
I'll
get
some
pr's
out
there
and
see
everyone,
then.