►
From YouTube: [OCI-WG] Reference Types - 2022-03-22
A
D
A
B
It's
it's
fun
when
it's
got
a
couple,
different
spellings
that
different
people
know
from
whoever
they've
met
in
their
past,
and
so
I
I
think
back
to
the
days
when
I
would
sit
next
to
someone
that
was
a
brendan
in
high
school
and
no
matter
what
the
teachers
said.
We
would
intentionally
sit
right
next
to
each
other,
no
matter
which
one
the
teachers
said
that
they
were
like.
You
mix
this
up
again
drove
nuts.
A
Yeah,
okay,
ready
josh
got
your
camo
gear.
You
look
about
as
ready
ready
as
you
can
be
excellent.
Okay,
okay,
so
I
I'm
happy
to
share
unless
anybody
else
would
like
to
do
it.
A
I
I
kind
of
feel
for
everybody
having
to
suffer
through
my
nasally
australian
accent
every
week,
so
if
anybody
else
would
like
to
do
it,
I
hold
no
reserve
no
ego
to
have
to
do
this.
Okay,
hello
and
welcome
everybody
to
the
working
group.
Ref
types
in
oci
today
is
tuesday
march
22nd
2022.,
it's
lovely
to
see
all
your
faces,
just
a
friendly
reminder
that
we
are
under
the
oci
code
of
conduct
and
it
states
please
be
lovely
to
each
other.
This
will
be
recorded
and
posted
to
youtube
after
the
fact.
A
So,
if
you're
catching
us
from
the
recording
hello
and
welcome
today,
we
have
a
full
agenda.
I
will
ask
that
anybody
in
the
audience
today,
please
add
your
name
as
to
the
attendees
list
in
in
the
hackmd.
That
would
be
very
fantastic.
So,
thanks
for
doing
that,
we
already
have
a
note
taker
brandon
mitchell
has
signed
up.
Thank
you
very
much
brandon.
You
get
the
emoji
gold
medal
for
today.
A
We
appreciate
that
and
we
do
go
ahead
and
check
all
these
minutes
into
the
github
repository,
which
is
great
progress.
Excellent.
So,
with
that,
I
will
get
into
the
agenda
from
top
down
order.
We
have
first
up
review
proposal
be
with
josh.
I
pass
you
the
virtual
mic,
josh
all
right.
We
see
your
screen.
C
So
this
proposal
was
originated
by
dan,
my
new
boss
here
at
chain
guard-
and
this
was
back
in
just
over
a
year
ago,
so
I
have
taken
the
liberty
of
putting
together
trying
to
simplify
what
he's
put
here
into
proposal,
but
just
to
be
clear.
C
This
is
this
is
not
mine
and
he
was
unable
to
make
it
today,
so
we
may
need
to
if
I
can't
answer
certain
questions
put
together,
a
log
of
of
things
to
answer
about
it,
but
very
simply,
primarily,
this
proposal
introduces
a
new.
C
A
new
field
on
all
of
the
image
spec
on
all
the
image,
spec
defined,
json
schemas
and
there's
a
link
here
for
a
pr
that
dan
had
put
together
and
you
can
see
like
on
the
go
level
for
descriptor
and
index
and
manifest
we're
just
adding
a
reference
which
is
itself
a
descriptor
and
what
that
allows
you
to
do
is
to
sort
of
after
the
fact
point
to
something.
That's
already
in
the
registry.
C
C
And
that's
pretty
much
it
for
the
schema
changes.
It's
not
there's
no
new,
manifest
or
there's
no
new
additional
schema.
It's
just
adding
this
one
new
optional
field
and
then
in
order
to
do
the
actual,
like
querying
after
the
fact,
adding
a
slash
references
dangling
off
of
the
manifest
to
a
given
reference,
either
tag
or
digest-
and
this
is
it's
really
just
an
array
of
descriptors
and
this
itself
is
a
valid
image.
Spec
index
with
really
just
the
manifests
fields
filled
out
here,
which
is
the
only
like.
C
D
C
So
pretty
pretty
straightforward,
in
my
view,.
B
B
The
the
quick
summary
from
talking
about
this
with
the
rest
of
the
of
the
oci
group
last
week
was
that
there
is
a
potential
that
we
could
run
into
registries
that
have
issues
with
some
of
the
looping
and
so,
as
a
result,
adding
the
reference
type
onto
the
index
would
be
a
challenge.
Would
would
not
be
good
I'll
I'll
phrase
it
that
way,
you
don't
want
to
be
able
to
yeah
go.
C
B
Yeah,
it's
if
you
ever
have
an
object
that
has
children
that
could
also
be
pointed
to
by
the
reference
type
itself.
That's
where
we
get
funny
loops
and
so
because
an
image
doesn't
have
children
that
are
other
manifest.
If
you
have
a
reference
that
can
only
be
a
manifest
you've
prevented
that
issue,
so
that
was
one
of
them.
I
was
thinking
of
go
ahead.
B
Yeah
I'd
I've
been
chatting
a
little
bit
with
dan
on
the
side
too,
on
this
stuff,
I
think
we're
all
looking
toward
the
same
direction.
Hopefully.
B
D
B
Go,
I
was
just
queuing
up
the
next
finisher
questions,
okay,
so
the
other
one
I
was
thinking
of
is
should
reference?
Do
we
want
to
consider
whether
reference
should
be
a
list
rather
than
just
a
single
descriptor?
Are
there
potential
use
cases
out
there,
where
you
might
have
more
than
one
thing
that
this
object
references
and
then
think
about
the
scenario
where
you
maybe
build
a
multi-platform
image
and
you've
got
one
s
bomb
you've
generated
for
all
the
platforms
you
just
built.
B
Should
you
be
able
to
have
that
same
s?
Bomb
refer
back
to
all
the
different
various
digests
to
the
different
platforms
in
the
index
and
whatnot.
C
I
I
think
john
actually
suggested
this
and
I'm
not
really
sure
the
what
the
conclusion
was,
but
I
don't
I
don't
see
why
not
you're
saying
this
would
be
basically
an
array
instead
of
an
object
with
descriptors
inside.
B
B
B
I
think
we've
got
a
condition
where,
depending
on
whether
you're
you
know
what,
if
that
reference
right,
there
was
called
manifest,
because,
depending
on
what
you
are,
you
might
be
looking
for
the
manifest
manifest
repository
and
finding
the
tag
name
reference
or
you
might
be
looking
for
references
on
the
upstream
repo.
I
think
we've
got
a
name
in
there.
B
B
And
then
the
only
last
thing
I
have
in
here
before
I
turn
it
over
to
steve
was
pagination,
and
I
know
you
mentioned
it.
You
know
that
was
something
you
were
thinking
about.
There.
C
Yeah,
I
think-
and
I
think
the
proposal
a
actually
has
a
lot
of
great
stuff
related
to
that,
and
I
don't
see
why
you
know
certain
aspects
of
that
for
like
wanting
to
query
a
certain
media
type
or
paginate
would
change
this.
The
essence
of
this
api.
A
Just
had
one
quick
one
brandon
before
you
turn
it
over
to
steve.
On
the
I
was
reviewing
your
feedback
about
hey,
there's
too
much
detail
in
proposal
a
and
I
suggested
hey.
Do
we
want
to
cut
everything
below?
That's
not
in
out
you
know
below
the
south
side
of
the
http
api
stuff,
which
includes
the
pagination
stuff,
so
I
just
whatever
you
describe
here
was
we
were
preemptively
answering
a
question
in
the
proposal
that
we
knew
was
going
to
come
up.
B
I
think
where
I
was
going
with
thinking
about
yours
was
we
got
into
a
lot
of
detail
in
there
of
here.
Is
the
rfc
to
go
look
up
for
all
these
other
details
and
it
got
to
be
very
wordy
very
quick,
and
so
the
good
thing
that
I
like
about
what
josh
had
done
here?
I'm
sorry
for
my
third
coin
out.
I
think
I
got
a
little
bit
of
cracker
in
my
third.
The
good
thing
I
like
about
it
is
we
just
really
focused
on
here's.
B
The
api
call
here
is
the
response
we're
gonna
see
from
it
here
is
the
json.
What
it's
gonna
look
like
we
didn't
really
get
into
describing
here
is
every
field
in
the
various.
This
is
optional.
This
is
mandatory.
This
is
the
other
yeah,
the
very
syntax,
for
every
field
we've
got
in
here.
It
was
just
here's
the
data,
it
doesn't
make
sense
just
looking
at
it.
Let's
talk
about
it,
yeah,
that's.
A
That's
that's
fine,
you
know
steve
and
I
and
sergey
when
we
were
doing
it,
we
either
said
hey
you're,
either
solving
this
by
inline
comments
with
the
slashlash,
which
is
basically
defining
what
the
field
does.
If
it's
not
infinitely
obvious
or
everybody's,
going
to
ask
a
million
questions
like
last
week
as
to
what
field
did
and
we
you
have
to
end
up
having
to
type
it
all
out
in
the
notes.
A
So
I
just
said
why
don't
we
just
put
it
there
and
then
but
hey
we're
we're
trying
to
fill
this
out
because
I
felt
like
I
think
it
was
niches.
Everyone
was
like
well,
what's
this
field
or
what's
that
field
and
is
it
optional
and
is
it
mandatory
and
is
it
an
array,
and
is
it
a
so
I
just
said:
well,
let's
start
here,
but
we
could
trim
it
back,
which
would
mean
you
know.
B
Yeah
that
that's
my
own
personal
opinion,
I'm
throwing
out
there
for
anybody
else
that
wants
to
chime
in
if
you've
had
a
chance
to
look
at
what
was
been
on
the
pr
for
a
josh.
I
think
you
had
been
one
of
the
people
that
was
looking
to
try
to
get
the
stuff
streamlined
down.
So
if
I'm
out
of
line
on
that,
one
feel
free.
C
I
generally
agree,
and
I
think
one
of
the
one
of
the
things
when
we
put
together
this
template
is
this
link
section.
C
You
know
if
you're,
if
you
have
like
this
huge
thing
on
the
pagination
and
filtering,
I
think
maybe
in
the
api
section
you
say
we
can
use
these
fields
in
these
fields
to
filter
and
paginate,
but
then
like
actually
just
link
out
and
keep
this
document
as
small
as
we
can,
because
I
think,
I
think
part
of
the
reason
why
we
this
working
group
is
here,
is
trying
to
communicate
these
ideas
and
not
get
lost,
but
it
again
like
I,
I
I'm
I'm
excited
that
that
you
all
put
it
together
and
I
think
with
just
a
few.
A
F
C
F
C
C
All
right,
so
it
was
seen
any
any
before
we
move
on.
A
D
Well,
I'm
just
gonna
build
on
some
of
the
questions
I
mean.
I
think
the
can't
remember
where
the
discussion
was
because
there's
been
a
couple
places
for
this.
The
the
reference
on
blobs
rather
than
manifest
is
the
one
that's
kind
of
problematic
and
we
hadn't
really
identified
what
the
use
case
is.
If
you
put
a
a
reference
on
the
core
descriptor,
then
basically,
everything
in
the
registry
can
be
a
tangled
vine
and
there's
no
way
to
have
any
kind
of
life
cycle
management,
and
this
is
part
of
what
brandon
was
kind
of
echoing.
D
D
So
that
was
one
of
the
things
and
we
couldn't
identify
a
solid
use
case
for
it.
So
that's
kind
of
why
we
kept
the
reference
up
at
the
manifest
in
the
artifact
wanted
subject
here.
It's
referenced
other
than
that
they're,
the
same
so
kind
of
echo
that
one,
the
other
one
was
the
reference
as
a
collection.
We
also
went
through
that
one
also.
We
were
trying
to
figure
out
what
they
could
do.
You
could
always
if
it's
a
collection,
you
could
always
say
it's
a
collection
of
one
and
use
that
use
case.
D
D
Yeah,
I'm
agreeing
that
reference
should
be
a
single
because,
as
we
expanded
to
try
to
make
it
a
collection,
we
couldn't
really
find
a
solid
use
case
for
it
and
it
made
the
lifecycle
management
also
extremely
complex,
to
try
to
manage,
because
you
have
one
thing
that
manages
down
to
graph.
Then
one
thing
that
manages
up
to
a
graph-
and
we
couldn't
really
find
the
scenario
to.
I
think
brendan
mentioned
this
as
well:
brandon,
sorry
that
the
you
could
point
it
to
an
index
and
that's
the
way
you
could
kind
of
manage.
D
If
you
want
to
do
up,
because
even
the
multi-arc
scenario,
I
really
struggled
to
find
a
single
s-bomb.
That
actually
is
the
s
button
you
use
for
multiple
architectures.
Each
architecture
would
have
an
s
bomb,
but
if
you
really
wanted
to
have
an
s-bomb
or
something
on
a
manifest
sorry
on
a
manifest
list,
then
you
can
make
an
s-bomb
on
the
manifest
list.
So
you
can
actually
achieve
both
so
I'll.
Stop
there,
because
I
see
brandon.
Do
you
have
a
question
on
that.
B
Yeah,
when
you're
saying
we
can
point
up
to
an
index,
I
think
that
still
has
a
challenge
where
somebody
says
give
me
the
s
bomb
for
this
individual
platform,
specific
image,
it's
not
going
to
search
back
to
the
index
to
find
the
s
bomb.
It's
you're,
going
to
have
to
upload
a
separate
s
bomb
for
every
platform.
D
Yes,
yes,
if
you,
because
by
the
time
you
you're
right,
if
you
put
a
multi-arc
s-bomb
on
the
index,
the
way
the
container
systems
work
is
it
asks
for
the
platform-specific
manifest
and
by
the
time
it
gets
that
platform-specific
manifest.
It
doesn't
necessarily
know
how
to
get
back
to
the
index.
So
that
kind
of
reinforces
that
that
problem.
B
Yeah,
so
you
would
end
up
having
to
just
upload
multiple
of
these
yeah
if,
if
there
are
issues
that
this
causes
I'd
have
to
think
through,
when
you're
saying
you
know
multiple
graphs
in
there,
then
we
have
an
option
to
work
around
the
other
way.
So
it's
not
a
a
deal
breaker
either
way.
A
D
And
then
the
next
one
is,
I
was
kind
of
curious
if
you
scroll
down
to
your
index
list
with
the
response
of
references
in
the
example
I
was
struggling,
because
I
don't
know
how
the
media
types
would
actually
be
vanilla,
chocolate
and
strawberry,
because
I
believe
those
the
descriptors
of
the
manifest.
So
those
would
all
be
image
manifest.
D
D
C
Oci,
this
should
probably
be
oci
image
manifest,
and
then
we
can
do
a
oci
artifacts
type
deal
with
the
vanilla.
Is
that
sort
of
right
here.
D
Yeah,
so
that's
kind
of
how
we
got
to
in
proposal
a
why
the
media
type
is
oci
image
or
oci
artifact,
whichever
it's
the
manifest
and
the
artifact
type
is
a
different
property,
because
that
what
I'm?
Basically,
what
would
happen
is
those
media
types
would
all
be
oci
image
or
oci
artifact,
whichever
in
other
words
those
are
the
manifest
types.
And
then
you
want
to
say
this
is
vanilla,
chocolate
and
strawberry,
and
that
would
be
the
artifact
type
property
that
you
see
in
proposal.
A.
D
C
D
And
then
the
last
one
is
just
like
putting
the
reference
putting
anything
on
the
existing
image
manifest
any
schema
changes.
This
is
just
back
to
the
original
problem,
like
we
can
put
subject
or
reference
on
a
manifest.
Technically,
the
question
is:
what
is
the
versioning
impact
of
that
if
we
just
jam
a
property
into
the
manifest
the
the
whole
premise,
especially
when
you
get
to
your
references
api
is
the
expectation.
D
Is
a
registry
knows
how
to
index
it
and
put
it
you
know
and
emitted
out
if
we
put
a
reference
put
any
new
property
name
on
a
manifest?
Is
that
a
version
bump?
Is
that
not
a
version
bump?
What
is
our
commitment
to
versioning
if
it
just
shows
up
in
a
registry
that
doesn't
know
anything
about
this?
Is
it
expected
to
persist?
Do
we
expect
to
get?
Are
they
magically
expected
to
provide
the
references
api?
So
that's
just
goes
back
to
it's.
It's
really.
D
C
D
Yeah,
that
was
that
was
an
interesting
one.
We
discussed
also
in
one
of
these
meetings,
like
must
ignore,
by
who
the
client
the
registry
like
there
was
a
very
you,
I'm
not
ominous.
It
was
a
very
vague
comment
that
sounds
and
feels
good,
but
if
you're
ignoring
anything
gets
put
in
it,
then
what's
the
expectations?
Are
there
expectations
you're
going
to
do
something
with
it?
So
it's
that
is
that
kind
of
a
nebulous
comment.
So
I'll
stop.
B
B
B
I
do
really
like
the
idea,
though,
of
modifying
the
image
itself,
and
the
reason
is
because
it
gives
us
a
nice
backwards,
compatibility
path
where
we
can
modify
this
image
media
type
with
an
extra
field
and
registries
that
don't
know
what
to
do
with
this.
B
As
long
as
they're
not
filtering
these
fields,
they
don't
know
deal
with
which
we've
seen
that,
so
that
is
a
possible
risk
out
there.
But
if
they
aren't
doing
that,
which
is
a
lot
of
the
registries
out,
there
aren't
filtering
by
any
unknown
fields.
We
can
push
this
image
manifest
up
to
a
registry
and
it
will
just
get
accepted,
as
is
without
any
changes,
and
the
reason
that's
nice
is
that
we
can
have
the
same
artifact
going
from
a
registry.
B
It
supports
new
media
types,
the
one
that
doesn't
support
it
and
for
the
ones
that
don't
support
the
new
api
calls.
We
could
have
the
the
digest
tags.
We
were
looking
at
before,
as
kind
of
like
the
backwards
compatible
solutions
for
those.
So
we
have
a
pattern
that
works
as
you're
moving
these
from
one
registry
to
another
that
you
wouldn't
have
to
actually
modify
the
digest
of
the
artifact
that
we're
adding.
C
Okay,
but
how
would
you
determine,
I
think,
like
what
steve's
saying
correct
me
steve
if
I'm
wrong
like
how
would
you
actually
determine
that
compatibility.
B
If
the
api
to
query
reference
doesn't
come
back
if
at
four
or
fours,
or
comes
back
with
a
answer
that
you
are
expecting,
then
you
would
know
to
push
the
digest
tags.
C
But
okay,
but
I
guess
I'm
just
thinking
about
the
like
the
workflow,
I'm
releasing
something
and
I
push
it
up
with
this
reference
and
then
two
days
later
I
go
and
I
try
to
pull
it
and
it's
not
there.
So
you're
saying
query
this
slash
references.
B
As
part
of
your
project
yeah
as
part
of
your
push,
unless
you
have
another
way
to
know
whether
the
registry
supports
you
or
not,
to
do
a
query
on
push
and
that
way,
if
you
see
it,
the
registry
doesn't
support,
then
you
know.
Okay,
I
also
need
to
push
these
tags
and
similar
if
you're
querying
registry,
you
say
give
me
all
the
references
to
this
image.
If
it
comes
back
and
says,
I
don't
know
what
that
reference
api
is
you're
asking
about,
then
you
know
to
go.
Look
for
the
tags.
A
A
A
B
D
D
A
D
D
A
Know
we've
tripped
over
this
wire
in
kubernetes
many
times,
adding
optional
fields
and
not
versioning
the
apis,
and
then
we
get
all
kinds
of
pickley
problems
later,
because
optional
additions
aren't
versioned
in
kubernetes
and
you
get
this
problem
with
forward
and
backward
compatibility
that
is
kind
of
unforeseen.
Just
it's
just
an
interest.
That's
I
was
just
wondering
you
know:
can
you
guarantee
that
if
you
say
if
you
put
that
data
there,
that
descriptor
does
every
registry
persist
that
data?
And
if
the
answer
is
yes,
then
it's
okay,
but
otherwise
it's
data
loss.
B
Yeah,
because
it's
data
loss,
they
threw
it
in
the
spec
that
you're
not
supposed
to
drop
those
fields,
you're
just
supposed
to
pass
them
through
as
unknown
and,
and
that
was
for
that
same
purpose
of
just
okay.
Knowing
that
you
wouldn't
know
all
the
fields
are
going
to
come
in
the
future,
so
just
allow
them
pass
through.
D
If
you
think
about
the
way
the
digest
work,
so
we
we
can't
actually
touch
the
contents
of
the
document
that
comes
in.
We
we
get
it,
we
validate
it,
for
instance,
a
manifest
that
has
the
layers
collection,
those
blobs
neat.
Well,
almost
I'm
careful
to
say
have
to
exist
because
I
have
to
go
back
and
look
at
the
wording
of
the
specs,
but
basically
the
typical
scenario
is
you
upload
the
blobs?
D
The
question,
though,
is
if
you're
sticking
properties
and
well,
first
of
all,
if
you
stick
in
properties
in
it,
is
there
an
expectation
we're
supposed
to
do
something
with
it?
Are
we
supposed
to
index
the
subject,
reference
property,
because
your
expectation
is
you're
going
to
get
something
out?
Are
we
supposed
to
not
garbage
collect
something
because
that
subject
references
something
in
some
graph
that
you're
expecting
to
be
persisted
and
then
to
your
size,
thing
yeah,
you
could
push
anything
you
want
into
it.
E
D
A
All
the
behavior
is
very
deterministic,
based
on
the
existence
of
that
referrers
api
on
the
http
endpoint.
C
Yeah,
I'm
just
struggling
with
how
you
know
that,
besides
making
a
real
request-
and
I
I.
A
A
D
It
would
return
it
so
implicitly
the
refers
api
would
be
there
if
you
understood
that
manifest
type
in
this
case,
if
we're
adding
properties
to
an
existing
image,
the
existing
image
spec,
are
we
bumping
the
version
if
we
bump
the
version,
I
don't
know
what
happens
to
register.
I
haven't
tried
this
like
if
you
say
that
the
manifest
media
type
is
a
version,
one
point
one
or
one
point
n
or
2.0.
D
I
honestly
don't
know
what
registries
would
do
if
you
submitted
it
to
it
and
if
you
don't
submit
it
because
we
say:
oh,
we
don't
want
to
break
registries
because
we
want
to
jack
it
into
existing
registries.
Is
there
an
expectation
that,
because
the
property
went
in
that,
there's
an
expectation
to
get
it
out?
So
all
this
just
kind
of
revolves
around
versioning.
E
E
I
don't
want
to
kind
of
take
away
from
the
proposal
that
josh
has,
which
is.
There
are
some
changes,
which
is
the
media
type
that
was
called
out,
but
we
can
fix
that.
The
fact
that
the
reference
element
is
added
does
not
break
image
spec.
It
might
be
a
registry
specification
change
and
that's
an
option
we
can
discuss
going
forward
when
we
try
to
take
things
forward
right.
So
can
we
when
we
fill
the
rubric?
E
I
think
it
will
be
more
clear
as
to
what
are
the
things
that
are
competing
here
and
what
can
be
taken
from
this
specification?
The
reference
type
does
look
appealing
in
some
way.
I
mean
in
a
lot
of
ways.
I
think
brandon
already
called
out
like
adding
a
feel
to
the
manifest,
does
make
a
lot
of
difference.
E
So
maybe
we
could
take
this
part
of
the
proposal
b
as
well,
but
the
versioning
aspect-
let's
I
would
recommend
we
should
look
at
both
sides
like
maybe
distribution,
is
what
we
need
to
version,
not
the
not
the
image
manifest
itself
and
that's
one
option
we
haven't
spoken
about.
Yet
I
want
to
hear
what
other
people
think
on
the
call
as
to
is
that
something
we
can
do,
because
we
are
changing
the
registry
api,
we're
adding
something.
E
So
there's
got
to
be
some
indication
that
the
registry
is
supporting
something
new
as
well,
but
we
never
look
at
the
registry
distribution
version
here,
which
is
something
we
should
look
at
as
well,
and
that's
that's
been
one
of
the
challenges
we've
faced
being
able
to
split
distribution
and
image
spec
as
a
both
as
a
storage
and
a
delivery
mechanism.
Here
right.
C
I
think
that's
a
that's
a
fantastic
point.
I
if
I
understand
correctly
you're,
saying
image
with
this
proposal.
Image
spec
requires
no
version
bump
if
we
trust
this
ignoring
fields,
but
the
regis,
but
but
distribution
would
need
a
1,
1
or
2
0,
and
we
would
need
a
way
to
know,
and
I
don't
know
what
that
way
is.
Is
it
the
conformance
page.
E
I
don't
know
those
are
options,
ignoring
the
media
type
mismatch
here.
I
think
that's
something
we
can
fix
and
specifying
how
the
how
this
is
a
specific
type.
That's
another
area
that
we
need
to
fix
in
the
rubric
that
might
conflict,
but
you
might
not
be
hitting
the
version
issue
specifically,
is
what
I'm
thinking
again
from
from
a
proposal
standpoint.
This
is
this
is
where
it
is,
is
what
we're
understanding
right.
E
C
Yeah-
and
I
would
say
it's
just
not
it's
just
not
part
of
the
proposal,
I
do
think
we
have
to
fix
whatever
we
decide
to
do
with
the
media
types,
but
I
think
filtering
and
pagination
are
just
simply
not
part
of
the
proposal
and
it's
something
that
we
can
take
from
a
or
c
with
our
final
kind
of
recommendations.
E
E
E
B
I
I
really
like
the
idea
of
taking
the
good
ideas
from
all
of
these,
and
so
don't
get
stuck
on
any
one
solution
of
okay.
We
can
only
implement
as
this
one
solution
is
there.
If
we
see
some
good
ideas
from
other
solutions,
let's,
let's
come
up
with
the
best
thing
we
come
up
with
the
working
group
result.
B
A
I
I
wanted
just
to
say
that
any
other
topics-
I'm
hearing
no
new
topics,
it
sounds
like
we've
called
out
all
the
ones.
Is
there
anybody
else
on
the
call
that
would
like
to
speak
up.
A
Okay,
thank
you
very
much
josh
for
presenting
that
really
appreciate.
It.
You'll
find
everything
in
the
minutes
and
the
notes
there.
Thank
you
very
much
brandon
next
one.
We
have
updates
for
proposal
d
with
brandon.
B
Yeah,
so
I
had
a
couple
of
them
out
there,
a
couple
pr's,
and
so
I
just
want
to
point
those
out
real,
quick.
B
B
Let
me
get
this
set
up,
so
I
can
actually
see
your
hands
when
you
start
raising
them
at
me
and
yeah.
So
this
I
had
gone
through
a
couple
weeks
after
we
went
through
the
proposal
d,
and
I
made
a
bunch
of
updates
over
here
fixing
things
like
using
or
grouping
containers.
B
I
think
I
changed
a
couple
of
those
references
over
there
document
the
annotations
up
top
that
we
are
changing,
and
then
I
streamlined
a
few
things.
I
think
I
took
out
one
of
the
examples
down
below
and
made
a
few
other
changes
started.
Embedding
some
inline
comments
as
well
in
different
places.
So
if
there
are
any
questions
on
that
throw
them
out
there,
otherwise
I
think
we've
got
enough
approvals
over
there.
B
We
can
merge
this,
so
I
just
want
to
do
a
last
call
for
anybody
that
had
questions
or
comments
on
that
one,
for
example,
I
did
take
out
option
two
from
this
one.
This
is
option
two
they're
all
numbered
one
option.
Two
did
not
have
the
hash
of
whatever
we
were
talking
about,
and
so
I'm
taking
that
out
and
saying
everything
you
push
must
need
a
hash
and
the
thought
process
I
had
behind.
B
That
was
thinking
that
we
may
want
to
include
a
reference
type,
no
matter
what
for
everything
when
you
push
it
up
there,
even
if
you're
the
original
creator
of
this
stuff.
So
it's
easy
to
go
back
and
look
up
things,
especially
if
you
upload
an
index,
and
you
want
to
be
able
to
pull
that
if
you
pull
by
digest,
you
want
to
be
able
to
go
back
and
find
by
that
hash.
The
reference
types
on
that
image
or
on
that
index,
so
a
few
changes
in
there.
B
B
So
that
was
one
of
them,
the
other
one
out
there,
the
image
layout
requirement.
I
had
the
other
pr
sitting
out
there,
so
that
one
make
sure
I
got
all
these
things.
I
had
one
that
didn't
make
the
cut
earlier,
and
so
I
was
throwing
into
our
requirements
list,
and
so
this
will
be
one
more
item
in
there,
which
was
that
I
wanted
to
support
the
image
layout.
The
file
system
format
so
in
case
you're
not
familiar
with
that
image.
Spec
itself
has.
B
This
is
the
file
system
layout.
When
you
pull
these
things
on
disk,
where
it
says
you
need
a
blobs
directory,
an
oci
layout
file,
an
index
json
file,
exactly
what
goes
in
them.
There
is
a
somewhere
in
here.
They
specify
exactly
what
the
annotation
is.
It
needs
to
go
on
this
few
other
details
in
there
about
what
it's
supposed
to
look
like,
and
so
this
is
the
file
system
format
that
if
you
export
an
image
locally,
you
want
a
sneaker
net
across
into
an
air
gap
network.
Something
like
that.
B
This
is
the
path
a
lot
of
people
are
going
through,
and
so
I
just
want
to
document
that
if
you
sneak
or
net
an
image
across,
it
would
be
nice
to
be
able
to
also
sneaker
net
all
the
references
to
that
image
across
as
well.
So
that's
why
I
was
looking
for
the
backwards
compatibility
support
for
this
one
featuring.
So
I
had
an
extra
item
in
there.
So
I
think
that's
another
one
of
those
where
I've
got
enough
approvals
on
there.
We
can't
merge
it,
but
I
just
want
to
throw
it
up.
B
E
B
Yeah
awesome
so
other
than
those
two
I
mentioned
my
we're
gonna
be
really
quick,
and
so
that's
why
I
was
doing
josh.
Take
all
the
time
you
want.
Last
week
we
were
talking
about
the
discussion
of
whether
or
not
we
had
this
looping
case
in
here
and
just
a
quick
reminder.
You
got
a
tag.
You
got
an
index
that
points
to
a
list
of
images
for
platform-specific
images.
They
point
to
blobs.
B
We
can
put
an
artifact
theme
points
up
to
an
index,
but
what
the
artifact
itself
points
to
is
important
in
terms
of
what
are
its
children
and
can
an
artifact
itself
contain
manifest,
or
can
it
only
contain
blobs
as
its
forward
references,
not
the
thing
that
it
refers
to
backwards,
but
the
thing
that
the
artifact
is
made
up
of
itself
and
oci
said:
please
don't
break
our
registries,
make
sure
that
artifacts
can
only
point
to
blobs
if
they're
going
to
have
a
reference
coming
out
of
them.
So
that
was
where
my
comment
to
you.
B
Josh
was
saying:
artifact
itself
cannot
be
an
index
because
then
it
could
point
back
to
the
manifest
and
also
forward
point
to
the
manifest,
and
then
you
get
this
funny
loop
with
garbage
collectors,
and
that's
not
just
us.
This
was
just
when
he
came
with
this
universal
proposal
for
everything
he
pulled
it
because
of
this
issue.
B
Nisha-
and
I
probably
have
to
have
a
conversation
when
she's
feeling
better
about
what
can
be
done
about
the
node
proposal.
She's
got
because
I
think
the
same
issue
is
over
there.
So
it's
it's
part
of
a
challenge
whenever
we're
trying
to
have
this
case,
where
we
want
to
say
if
an
artifact
points
to
an
image
that
we
don't
delete,
an
untagged
artifact,
and
so
because
of
that
it
just
complicates
this
whole
picture,
and
so
the
feedback
from
oci
was
yeah.
We
agree,
that's
a
good
idea
over
there
and
so
don't
break
registries.
B
B
Yeah
it
it's
not
the
first
time
I
made
this
picture.
We've
we've
gone
over
this
one
for
a
while,
and
I
think
it
was
just
since
we
were
coming
back
up
with
the
working
group
a
lot
of
people
that
hadn't
seen
it
or
remembered
it
from
way
back
in
the
day
you
might
have
forgotten
about
it.
So
is
a
good
one.
We
don't
want
to
break
so
that.
A
A
A
B
It
is
the
best
way
I've
thought
about
to
frame
it
is
take
whatever
your
artifact
is.
That
has
a
reference
type
on
it,
ignore
the
reference
type
for
now
draw
a
tree
of
everything.
You've
got
that's
built
off
of
it
and
then
make
sure
that
it's
not
possible
for
whatever
that
reference
type
is
to
point
to
any
object
in
that
tree.
B
That's
that's
the
best
description
that
can
come
up
for
it
if
they're,
better
ways
of
phrasing
it
by
all
means
throw
them
out
there,
because
I've
confused
a
lot
of
people
with
this.
A
Yeah
and
it's
it's
one
of
those
concepts,
that's
denied
into
any
any
tree
and
looping,
it's
just
like
what
is
the
terminology
that
people
cling
to,
so
that
they
can
associate
it
with
what
you're
trying
to
describe
here
rather
than
thinking
about
it,
like
some
net
new
topic
that
you're
this?
This
is
like
a
common
common
thing.
I
just
yeah,
I
don't
know
the
terminology.
I
was
just
racking
my
own
brain.
D
That's
where
I
try
to
capture
it,
because
this
is-
and
I
had
the
same
conversation
with
justin
actually
around
the
merkle
tree
concept
is
they're
all
based
on
a
downward
dependency
graph,
and
what
we're
doing
here
is
we're
creating
an
inverse
dependency
graph
as
well
at
the
same
time
and
there's
an
intersection
of
both
the
way
we've
been
able
to
mitigate
and
that's
extremely
powerful,
because
now
I
can
add
things
to
a
registry
that
say
they
add,
extend
information
to
existing
objects.
Those
existing
objects,
don't
know
about
them,
so
we're
not
changing
their
merkle
tree.
D
We're
just
saying
here's
some
additional
information
that
are
independently
verifiable.
The
I
think
where
we
came,
was
an
interesting
conversation.
The
oci
call,
I
guess
a
week
or
two
ago,
was
as
long
as
we
maintain
two
different
document
types
index
and
artifact
or
image
whatever.
Basically,
a
single
object
and
a
collection
of
objects
that,
as
long
as
you're
putting
the
backwards
pointer
to
on
the
individual
object,
we're
fine
like
we
won't
get
into
cycles.
D
So
it
it's
what's
interesting
about
that
is
justin
tried
with
his
pr
37
to
try
to
create
one
manifest
to
rule
them
all.
We
considered
doing
that
with
the
artifact
manifest
by
making
blobs
descriptors.
That
was
a
derek's.
You
know
an
idea
of
derek
had
and
the
more
we
explored
it.
We
still
couldn't
solve
that
problem.
So
I
think
what
we're
coming
back
to
is
saying:
two
manifests
individuals
and
a
collection,
and
the
collection
is
a
collection
of
individuals.
D
As
long
as
you
maintain
that
you
could
have
downward
markle
trees
and
upward
pointers,
and
you
don't
get
into
the
cycles
problem
and
we
haven't
found
a
scenario
that
requires
anything
more
than
that
anyway.
So
if
there
is
a
scenario
great,
but
should
we
throw
technology
at
something,
we
haven't
found
a
problem
for.
B
Yeah,
I
think
the
to
kind
of
throw
this
in
a
picture
here
that
the
solution
we
came
up
with
is
to
say
the
artifact
itself.
Whatever
has
that
reference
type,
it's
going
to
have
a
lower
kind
of
object,
type
under
it,
which
in
this
case
is
blobs,
and
you
can
never
point
to
that
lower
object,
type
with
your
forward
reference
and
therefore
your
backwards.
Reference
can
never
point
to
this.
A
A
B
D
Individual,
the
individual
manifest
can
point
to
blobs
the
index.
Can't
air,
quoting
can't
because
we
have
the
build
deck
scenario,
which
kind
of
violated
that
concept,
and
we
got
in
the
debate
of
the
definition
of
a
manifest
is
somehow
a
descriptor.
But
as
long
as.
B
D
A
Okay,
you
start
to
get
to
the
architect
in
the
matrix
visa
v.
You
know
I'm
starting
to
lose
what
what's
life?
I
need
to
spin
a
top
on
a
table
before
I
go
to
sleep
now.
Is
there
any?
Is
there
anything?
Is
there
anything
else?
You
start
to
twist
my
mind
in
circles.
I
need
to
go,
see
leonardo,
dicaprio
and
watch
him
around
yeah.
I
know
yeah
blow
up
a
fruit
stand
or
something
I
don't
know
what
the
what
they
were
doing.
A
What
level
of
dream
am
I
in
anyway
things?
Let's,
let's
wrap
up,
I
think
now
and
I'm
doing
proposal.
Is
that
correct
so
I'll?
Add
that,
to
the
add
that
to
the
tweak.
C
D
Think
the
question
is
what
you
know:
do
we
pull
all
the
details
out
that
we
wind
up
asking
or
do
we
leave
the
details
in
so
we
could
ask
the
next
level
of
details,
because
I
can
pull
all
the
details
out
and
then
every
time
a
question
comes
up.
I
can
just
paste
that
in
the
description
or
we
can
just
leave
it
in
and
then
figure
out.
What's
the
next
round
of
questions.
D
I
did,
but
I
did
pull
out
information
that
I
didn't
think
was
relevant
here
like,
for
instance,
it
doesn't
say
or,
as
it
says,
oci
because
the
assumption
is
a
merger.
There
was
a
bunch
of
details
that
we
also
pulled
out
to
streamline
it.
It
was,
it
was
actually
a
subset
and
the
information
that
was
kept.
It.
D
No,
it
doesn't
deviate
the
only
the
only
the
deviation
is
the
it's
oci
versus
auras.
Everything
else
is
the
same,
and
the
whole
idea
is
that
all
the
questions
that
we're
going
through
here
are
questions
that
we've
lived
in
real
life
as
we've
been
implementing
it.
So
we,
I
literally
just
kept
the
answers,
and
even
some
of
the
design
on
sorting
has
been
the
most
recent.
You
know
issues
that
come
out
of
this,
because
the
whole
idea
is
that's
great,
that
we
we
go
emerge
some
simplistic
version
of
it.
D
B
D
D
C
C
Yeah
there
was
just
a
few
things
like
the
biggest
one
I
found
is
like
the
very
top.
It's
like
a
small
description
and
then
also
that's
supposed
to
go
in
the
table
on
the
readme.