►
From YouTube: OCI Weekly Discussion - 2021-09-22
Description
Recording of the OCI weekly developer's call on 22 Sep 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-22-2021
A
A
Well
is
this
the
same
thing?
Let
me
just
okay,
because
I
I
looked
back
at
the
doodle
because
again
I
was
like.
Why
hasn't?
Why
didn't
it
ever
get
changed
because
it
looked
like
there
was
thursdays
at
I
mean
I'm
in
the
eastern
time,
but
still
thursdays,
12
p.m
and
1
p.m.
Eastern
we're
better
we're
like
the
most
chosen
day
at
which
would
be
nine
and
ten
pacific
and
still
pretty
decent
for,
like
six
to
seven
european
central
european
hayden
euro
gmt
plus.
A
D
A
B
Yeah,
it
was
also
unclear,
I
think,
before
who
would
lead
the
aipac
focused
meetings.
If
there
is
someone
here
who
is
interested
in
doing
that,
then
that
unblocks
the
issue,
but
I
think
that
was.
I
think
I
remember
that
being
the
issue
before
was.
We
would
like
to
split
into
two
things:
maybe
but
who's
going
to
leave
the
other
one
and
then
maybe
that
maybe
that
shouldn't
have
blocked
us
and
we
should
have
just
gone
to
thursdays
at
one
or
whatever
time
it's
been
said
with
us
and.
F
E
A
B
Who's
got
the
agenda.
I'm
the
first
item
on
the
agenda.
I
actually
only
have
about
10
minutes
before
I
need
to
leave,
so
I
will
be
quick
back
in
april.
There
was
a
call
for
more
maintainers
on
image
stack.
I
think
there
was
also
a
call
for
distribution,
spec
maintainers,
but
I
don't
think
that
that
was
as
nearly
as
as
urgent
an
issue.
I
went
back
and
wanted
to
see
if
we
made
any
progress
on
that
we
we
made
a
little
bit,
we
swapped
john
in
for
someone
else.
B
We
dropped
a
person
and
we
updated
some
email
addresses,
which
is
nice
hygiene,
but
ultimately
not
doing
a
lot.
I
wonder,
and
I
wanted
to
ask
folks
in
this
room
and
other
anywhere
else
if
we
think
that
is
a
sufficient
change
in
movement
to
call
that
issue
closed.
I
think
chris
closed
the
issue
after
that
comment,
because
I
think
he
interpreted
it
as
oh.
That
sounds
like
we're
done
and
then
closed.
A
My
personal
opinion
is
that
it
breathed
some
life
and
attention
into
the
topic,
and
people
are
more
people
are
already
involved
than
before,
and
I
wasn't
really
excited
about
the
process
in
the
first
place
of
just
kind
of
like
grab
bagging
a
bunch
of
people.
I
understand,
like
there's
a
need
and
a
time,
I'm
glad
that
the
charter
is
set
up
in
such
a
way
that
we
can.
A
But
I
think
that
there's
work
to
be
done
in
that
spec,
even
if
it
is
kind
of
like
doing
some
reconcile
with
like
things
that
we
wanted
to
get
into
the
image
spec
that
really
belong
in
kind
of
a
generic
place
or
distribution
spectre.
There's
work
to
be
done.
There,
there's
conversations
being
had
now
that
weren't
being
had
before,
and
I
think,
there's
a
tension
there
that
more
than
you
know,
any
new
maintainers
would
arise
from
those
conversations
and
effectively
appear.
You
know,
appear
and
be
nominated
in
the
normal
kind
of
processes.
B
The
short-term
solution
that
leads
to
it
is
for
people
to
have
to
be
more
interested
and
engaged,
and
that
is
working
as
a
result
of
that
issue.
Is
that
more
or
less
I
don't
know
if
that
cleared
it
up
or
made
it
worse,
but
working
or
rekindled
yeah
yeah
does
anyone
else.
I
I
don't
want
to.
Does
anyone
else
have
any
thoughts
on
that.
H
B
So
if
the
issue
is
is
inactive
maintainers,
then
I
think
it's
fundamentally
impossible
to
block
on
the
inactive
maintainer's
approval
to
fix
the
issue
right
or
or
like
if
you're
saying
this,
this
is
sufficient.
This
is
enough,
and
we
just
say
like
we're,
taking
those
no
votes
as
no
or
non
votes
as
no's,
then
these
are
no's
and
reject,
but
I
think
you're
right
sitting
sitting
with
open
proposals,
is
sort
of
a
weird
state
to
be
in.
D
Yeah
I
mean
this
was
the
problem
with
this
there's.
This
wasn't
as
simple
as
there's
a
gap
in
maintainers.
There's
some
questions,
we're
trying
to
figure
out
in
the
broader
scope
of
what
do
we
do?
What
do
we
think
about
with
the
various
projects?
There
was
some
very
tactical
things
like
your
pr
on
the
base.
Image
thing
I
forgot,
the
exact
property
name
is,
but
that
was
a
fairly
focused
one,
that
there
was
general
consensus.
It
was
just
worded,
so
there
was
activity
to
get
that
merged.
There's
this
larger
conversation
around.
D
How
do
we
make
the
next
evolutions,
whether
it
be
the
image
spec,
runtime,
stuff
or
the
stuff
we're
talking
about
with
artifacts?
That
is
it's
not
as
simple
as
just
some
maintainers
on
particular
projects.
That's!
So
that's
where
I
think
a
couple
of
the
prs
are
sitting
is
there
needs
to
be
a
larger
thought
process
put
together,
and
while
the
focus
on
trying
to
revive
some
maintainers
was
a
tactical
effort,
I
don't
think
it
really
solved
the
larger
problem,
which
is
what
I
think
you're
asking
about.
B
Yeah
I
mean
you
mentioned
the
the
base
image
annotations.
I
I
don't
consider
that
I
mean
it
merged
and
I'm
happy
that
it
did,
but
I
don't
consider
that
a
a
an
example
of
a
well-running
machine.
It
took
six
months
and
a
lot
of
hair
pulling
and
a
lot
of
cat
hurting.
You
know
it's.
It's
open
source,
there's
gonna
be
some
cat
hurting,
but
this
is.
D
D
B
Yeah,
I
think
the
the
the
amount
of
work
it
took
to
get
approval,
for
that
relatively
minor
thing
makes
me
think
that
anything
bigger
than
that
is
effectively
impossible,
whether
that's
an
image
spec
or
any
other
thing
like.
If,
if
this
is,
if
this
is
how
oci
operates,
then
I
don't
see
another
change
on
the
horizon
to
oci
broadly,
and
that
is
ultimately
long-term,
not
good
for
the
health
of
the
community
and
the
health
of
the
project
that
we
are
all
trying
to.
You
know
bring
life
into
I
just
wanted
to.
B
I
only
have
a
few
more
minutes
before
I
have
to
leave,
but
I
really
wanted
to
advocate
for
more
folks
to
well
get.
I
wanted
to
get
feedback
and
see
if
people
think
this
is
working
correctly
and,
if
not
like
me,
help
help
advocate
for
moving
in
the
right
direction
and
trying
to
get
more
maintainers.
Somehow.
F
B
B
H
You
know
quick
assessment
of
activity
and
we
we,
I
think
we
looked
it
over
months
ago.
You
know,
like
vincent
said,
this
is
a
tricky
area
where,
like
you
know,
we
we
have
processes
in
place.
To
like,
say
hey.
You
know
you
were
part
of
this
group,
but
if
you're
not
going
to
be
active
like
let
us
know
what
you
want
to
do,
do
you
want
to
be
archived
emeritus
whatever
and
it
seemed
like.
We
got
one
or
two
responses
to
that
in
the
moment.
H
A
B
B
Yeah,
I
I
have
no
prescribed
solution
to
this.
I
mostly
just
wanted
to
advocate
for
people's
thoughts
and
to
see
if
anyone
felt
the
way,
I
feel
or
felt
the
opposite
and
I
don't
know
either
way,
but
I
feel
like
those
the
three,
the
three
open
issues
related
to
this
are
somewhat
hair
balls
and
nobody
wants
to
touch
them.
B
B
B
B
D
E
E
E
A
I
I
would
I
would
say
that
if
you
want
this
project
to
be
open
and
like
others
to
feel
like
you
know
they
can
join,
then
there
should
be
that
laid
out
somewhere,
even
if
there
is
multiple
paths
to
become
a
maintainer
having
those
written
down.
Otherwise,
it
just
feels,
like
you
know,
you
kind
of,
have
to
be
an
insider
and
know
inside
people
to
be
a
maintainer.
J
I
Yeah,
I
think
I
mean
a
lot
of
the
maintainer
files
that
I've
seen
in
like
paths
to
being
a
maintainer.
That's
all
it
says
is
that
you
get
nominated
by
the
maintainer.
There's
a
two-thirds
vote
on
existing
maintainers
and
it's
you
know
the
criteria
for
why
that
person
might
nominate
you
can
vary,
but
having
at
least
some
formal
process,
I
think
is.
C
You
know
outside
of
that
they're
at
the
initial
state
right,
the
initial
creation
of
the
list.
There's
a
you,
know
a
process.
Okay,
do
we
want
to
create
this?
You
have
to
go
to
the
top
and
there's
nominations,
and
that
sort
of
thing
happens,
and
sometimes
it's
based
on.
Where
did
the
code
come
from
kind
of
thing
right,
so
yeah
yeah
coming
in
at
the
end
and
we're
waiting
on
a
reset
for
a
list
of
maintainers
and
sort
of
like
well?
How
does
it
happen
now?
C
If,
if
we,
if
we're
a
little
short
on
the
head,
account
to
get
over
the
two-thirds
majority,
it
can
be
tricky,
and
this
isn't
the
only
open
source
project
that
has
this
issue.
It
happens
a
lot
in
open
source
projects,
one
after
they
deliver
something
and
move
on.
You
know
it
you,
you
really.
You
almost
need
to
tie
it
down
at
the
end
to
say
people.
You
know
please
leave
now
if
you're
not
going
to
stay
yeah
and
thank.
C
I
A
D
But
I
think
there's
the
tension
in
the
room
is
that
the
elephant
in
the
room,
whatever
the
tension,
we
know
this
is
a
problem
we're
trying
to
make
some
progress.
I
don't
know
if
we
found
the
answer
yet.
I
think
there
was
a
desperate
hope
that
the
off-site
next
week
was
going
to
be
in
person
and
we
were
going
to
be
able
to
make
more
progress.
I
think
last
week.
D
I
K
D
K
D
Got
you
I
got
you,
okay,
that
inherently
yeah
there
is
some
people
that
are
on
site.
That'll
have
a
chance
to
talk
to
each
other,
one-on-one
and
it'd
be
great
if
there
was
a
way
to
do
that
virtual,
but
I
think
even
in
the
sessions,
that's
part
of
my
comment
around
the
allocations
for
time
is:
if
we're
trying
to
cover
three
meeting
topics
in
90
minutes,
then
we're
not
really
having
much
of
a
conversation
like
the
ideas.
H
Situation,
I
don't
know
if
this
helps.
If
the
question
is
more
practical
or
pragmatic,
like
I
think
those
of
us
who
are
trying
to
organize
discussions
like
we
just
need
to
have
a
framework
whereby,
like
one
of
us,
is
totally
dedicated
to
making
sure
that
anyone
who's
on
zoom
is
able
to
interject
ask
a
question.
H
H
A
A
I
I
think
I'm
the
next
so
the
a
couple
weeks
ago,
I
brought
up
the-
and
I
don't
know
folks-
have
the
link
from
meeting
agenda,
but
a
proposal
to
the
pearl
spec
to
add
oci
artifact
as
a
package
type,
and
the
idea
is
that
we
can't
currently
there's
a
docker
package
type
and
we
can't
remove
this
because
of
backwards
compatibility.
But
the
goal
is
to
move
it
towards
deprecation
just
in
the
by
way
of
people
not
using
it
and
instead
having
an
alternative
to
use.
I
The
general
goal
here
is
to
have
a
reference
to,
or
a
package
type
for,
artifacts
that
can
be
stored
in
oci
registries,
and
I
opened
the
proposal
there
was
some.
I
think
I
wanted
to
discuss
mostly
the
there's
some
objection
to
oci
artifact
as
a
name-
and
I
think
john,
if
you're
there,
maybe
you
can
start
with
what
you
see
as
objections
there
to
me,
it
seems
like
oci.
Artifact
is
a
general
way
to
reference
artifacts
stored
in
oci
registries.
I
think
most
pearl
users
we
aren't
going
to
be.
J
Yeah,
I
think
it
is
confusing-
and
I
maybe
that's
partially
my
fault,
so
artifacts
means
a
couple
things.
There
is
the
open
containers,
artifacts
project
that
was
proposed
and
approved
and
exists
as
a
repo
there's
also
the
term
artifacts,
which
generically
means
things
right.
So
when
I
think
we
were
just
talking
past
each
other
a
couple
weeks
ago,
when
I
thought
you
were
talking
about
artifacts
generically,
but
there
is
language
in
the
spec
that
is
about
the
artifacts
project.
J
Specifically
more
confusing
is
that
the
proposal
is
about
the
thing
you
thought
artifacts
project
was
so.
The
proposal
is
to
basically
refactor
the
open
containers
project
in
terms
of
the
artifacts
project,
but
that
is
not
what
has
happened
and
so
artifacts
means
a
different
thing
from
anything
stored
in
a
registry,
and
I
I
think
it
is
confusing
to
use
the
term
oci
artifacts
to
refer
to
anything
stored
in
a
registry,
especially
if
there
is
language
in
the
spec.
I
J
I
would
say
sorry
I
was
confused,
so
it's
not
just
the
string.
It
is
also
the
content
where,
like,
if
you're,
referring
to
the
thing
that
the
artifacts
project
calls
an
artifact
type
that
is
specific
to
the
artifacts
project
and
it
is
not
generically
oci
oci
generically.
You
would
talk
in
terms
of
digest.
Descriptors
media
types,
the
artifact
type
is
not
a
generic
oci
concept.
J
It's
not
the
the
language
in
the
pr
is
about
what
the
artifacts
project
calls
artifact
type,
which
is
defined
as
the
config
descriptor's
media
type
multi-platform
images
like
the
image
index
spec
does
not
have
a
config
descriptor
and
so
there's
no
way
to
reference
image.
Index's
artifact
type,
because
there
is
not
one.
J
E
So
let
me
just
quickly
clear
the
air
over
here,
what
we're
looking
for
what
pearl
the
spec
is
looking
for
is
a
package
type
and
what
the
pearl
community
is
asking
is
for
something
a
word.
That
indicates
a
thing
that
is
stored
in
a
container
registry
container
registries,
as
they
exist
right
now,
conforming
to
the
oci
distribution,
spec.
D
That's
more
because
npm
stores
npms,
like
what
we're
saying,
is
that
a
registry
can
store
lots
of
different
things
and
all
the
details
of
what
you
just
went
through
are
technically
accurate,
but
abstract
of
the
point
of
we're
just
trying
to
describe
how
things
can
get
stored
in
a
registry
and
there's
lots
of
things
that
can
be
stored
in
there.
So
I'm
not
sure
why
there's
such
a
hesitancy
to
something
that
is
very
generic
around
this
is
not
an
org
that
we're
talking
about.
Oci
is
an
org
there's.
A
D
D
D
C
Is
the
point
either
way
it
doesn't
matter
in
the
context
of
this?
This
plural
thing,
if
we
say
oci
which
are
or
if
we
say,
oci
dash
artifacts,
which
are
it's
it,
you
could
limit
it
either
way,
if
you,
if
you
want,
if
you
want
those
things,
just
to
be
the
images
that
we're
currently
storing
with
the
currently
defined,
you
know
manifest.
That's
perfectly
fine,
and
if
later
on,
we
want
to
add
to
that
list.
It's
also
perfectly
fine,
it
doesn't
matter
really
the
name
we
put
there.
C
D
C
D
I
just
think
we're
being
way
too
literal
we're
getting
we're
letting
the
details
get
in
the
way
of
sending
a
clear
message.
You
can
store
lots
of
things
in
a
registry,
this
isn't
just
npms,
and
this
is
similar
to
the
other
conversation
we
had
around.
The
maintainer
ship
is
not
just
as
simple
as
me
active
maintainers.
D
This
conversation,
this
debate
we
have
around
artifacts
and
registries,
has
caused
so
much
confusion
like
the
helm
team
is
still
confused
around
whether
we
actually
is
this
thing's
real
or
not
and
john.
You
said
a
couple
weeks
ago
who
do
I
you
know.
Why
is
this
a
confusion?
What
do
you
need
to
do
to
solve
it?
We
need
to
stop
being
confusing
around
the
message
that
you
can
store
lots
of
things
in
registering.
We
call
that
we're
referring
to
that
as
artifacts.
You
can
throw
lots
of
things.
D
J
D
Do
each
one
of
those
images
are
still
a
artifact
the
fact
that
you
could
have
a
collection
of
multi-platform
images
which
themselves
are
there's
still
an
image,
a
container
image
artifact
the
fact
that
you
can
pivot
on
it
doesn't
make
that
a
new
type.
It
just
means
that
you
have
an
index
that
looks
across
them.
This
isn't
so
literal
to
talk
about
the
actual
media.
It's
a
conceptual.
C
You
guys
are
both
right.
You
really
are
you're
both
right
and
it's
okay,
that
you're
both
right
right.
It's
cool,
I
think
one.
Something
to
think
about
is
that
the
oci
image
specification
does
not
restrict
right
registries,
and
nor
does
the
distribution
specification,
restrict
registries
from
storing
other
media
types.
Now.
That
said,
it
doesn't
mean
that
those
other
media
types
have
been
specified
in
oci
and
I
think
that's
what
john
needs.
So
we,
I
think
the
key
thing
is
it
doesn't
matter
really
what
we
we
could
call
it.
C
Oh
stuff,
we,
whatever
we
use
as
a
name.
We
have
to
say
why
we
use
that
name
and
what
does
it
mean
to
include
right,
but
whether
we
use
you
know
artifacts
or
oci
or
oci
dash
artifacts?
It
really
doesn't
matter
that
much
as
long
as
we
could
say
open
containers
initiative
if
they
would
allow
us
to
use
a
longer
name
right.
C
D
J
J
E
E
E
And
we
can
have
like
subtypes
from
there
on,
because
this
is
a
distributed
environment.
Anything
can
happen
in
the
future.
I
mean
for,
for
one
thing,
there
is
already
something
called
docker
in
the
in
the
spec.
That
only
has
to
do
with.
You
know
that
the
pearls
community's
understanding
of
what
docker
is
not
what
oci's
understanding
of
what
docker
is.
So
it's
kind
of
like
a
veggie
thing
anyway,.
I
J
Would
just
call
it
oci
it,
so
it
depends
on
how
deep
in
the
graph
of
objects
you're
talking
like
oci
artifacts,
the
project
puts
a
string
inside
the
image
that
represents
an
artifact
type
right.
You
have
to
pull
that
thing
and
then
pull
the
artifact
type
out
of
it.
So
in
the
current
pr
there's
some
discussion
around
what
type
means,
and
if
I'm
correct
me
if
I
misunderstood
this,
but
we
want
to
put
that
artifact
type
as
this
optional
type
field
right.
J
The
problem
is
that
that's
specific
to
one
of
the
two
types
of
images
that
you
can
reference
in
a
registry
there's
an
image
and
an
index
artifact
type
only
makes
sense
in
the
context
of
an
image.
If
you
want
to
be
able
to
use
perl
to
reference
multi-platform
images
like
all
of
docker
library
images,
you,
you
can't
use
the
concept
of
an
artifact
type,
it
has
to
be
the
media
type,
which
is
the
content
type
of
the
outer
json
object,
so
the
oci
image
or
the
oci
index
that
that's
the
more
general
thing.
I
I
I
I
I
J
I
J
Yeah
yeah
and
like
I
don't
like
arguing
semantics
for
fun.
I
think
this
is
important
like
if
it's
in
a
specification,
it's
important
that
it
means
something
specific
so
like
I
don't
love
putting
artifact
type,
but
I'll
accept
it.
If
it's
an
optional
thing
that
that
is
maybe
there
yeah,
but
I
wouldn't
call
it
type,
because
that
implies
to
me
that
it's
this
generic
thing
like
I
am
still
confused
about
what
string
you
want
to
put
there
and
that
shouldn't
like
a
spec
shouldn't,
be
that
ambiguous.
D
I
think
this
is
the
point
why
we're
using
the
yosoi
rfx
project
to
be
able
to
reference
this,
because
what
we,
the
agreement
we
wound
up
with,
is
the
image
container
image
runtime
type,
whether
it's
represented
as
a
man
effects
or
manifesto
index,
is
a
detail
that
is
really
a
matter
of
multi-platform
routing
of
the
same
thing.
It
just
says
this
is
a
container
image.
D
There's
a
pivot,
there's
a
detail
that
doesn't,
in
fact
there's
a
separate
property
for
architecture
in
perl
that
says
whether
it's
linux
or
windows,
so
anything
that's
an
index
or
an
image
can
still
be
referenced
as
a
container
image.
What
we're
trying
to
say
is
was:
is
it
a
container
image?
Is
it
a
helm
chart?
Is
it
a
wasm?
Is
it
a
you
know
an
opa?
Is
it
something
we
haven't
even
identified
yet
because
that's
the
whole
point
of
the
flexibility
is
you
shouldn't
have
to
come
to
this
body
to
define
a
new
type?
D
I
think
part
of
what
we're
getting
caught
up
into
is.
Yes,
there's
these
media
types
that
we
historically
use.
When
I
say
historic,
I'm
not
trying
to
say
I'm
trying
to
say
is
at
the
time
it
was
only
container
images.
We've
been
trying
to
figure
out.
How
do
we
leverage
what's
there?
So,
yes,
we
use
the
media
type
of
the
config
object
to
pivot
for
different
types.
D
The
concept
is
not
tied
to
the
media
type
of
the
manifest
it's
tied
to
the
the
artifact
type
of
what
it
is
you're
trying
to
represent
a
container
image
is
an
artifact
type
and
opa
is
an
artifact
type.
Well,
I'm
trying
to
get
into
this
wasm
conversation,
so,
let's
just
I'll
use
something
else
for
this
helm
chart.
Those
are
what
we're
logically
calling
artifact
types
and
if
you
look
at
what
we've
been
trying
to
do
with
the
most
recent
stuff
with
artifacts,
is
not
try
to
reinvent
yet
another
type.
D
In
fact,
this
was
your
feedback
that
we
already
in
artifacts
in
the
artifact
or
oci
artifacts,
we
said
use
the
iana
media
types
to
uniquely
identify
something
and
stick
that
on
the
config
object,
rather
than
trying
to
redefine
a
different
way
to
do
artifact
type.
Now
that
we're
first
classing
that
property-
let's
just
use
the
same
thing,
so
that's
the
it's,
it's
bubbling
up
to
the
most
simplistic
thing
of
what
is
it
we're
trying
to
represent
for
people
to
tell
them
and
that's
store
stuff
in
our
registry,
store
all
your
stuff
in
the
registry?
D
I
I
guess
john,
what
do
you
see
as
the
issue
with,
because
you
said
you're
not
like
we're
not
arguing
semantics,
just
because
like
this
is
the
distinction
is
important
in
the
way
that
pearl
would
be
used.
What
is
the
I
guess,
consequence
of
using
media
type
or
artifact
type
as
the
type
of
the
in
it
as
a
descriptor
in
the
pearl?
I
J
D
D
Container
image
is
probably
a
lot
of
them,
but
there'll
be
other
things
that
there
will
be
build
s
bombs
for
when
I'm
uniquely
identifying
that
thing
by
the
way.
What
type
is
it?
Is
it
a
container
image
or
is
it
a
helm
chart
if
it's
a
container
image?
And
it's
then
that's
the
important
thing
because
it
basically
says:
okay,
this
is
a
runtime
image.
I
I
They
are
producing
an
s
bomb
for
the
same
container
image,
and
while
the
naming
or
like
the
spdx
id
of
that
container
image,
the
same
container
image
is
going
to
be
different
because
maybe
they
have
different
naming
conventions
or
whatever
the
uri,
which
is
this
pearl
is
the
goal
is
that
if
somebody
was
looking
at
these
two
separate
documents
created
by
different
producers,
then
they
could
look
at
the
same.
They
could
look
at
this
ui
and
say:
okay,
that
is
the
same.
I
That's
the
same
thing,
and
it's
not
going
to
be
a
hundred
percent
like
it's
not
going
to
be
identical,
but
the
goal
is
to
get
it.
This
pearl
is
supposed
to
help
us
get
as
close
as
possible
to
recognizing
that
these
two
things
are
the
same
in
separate
documents.
That's
like
the
most
straightforward
case
for
where
it
would
actually
be
applied.
I
Yeah
and
you
don't
have
to
do
the
type
like
all
of
that,
the
all
of
those
optional
qualifiers
are
just
hints,
they're
not
actually
used
when
comparing
the
equalness.
I
don't
think
that's
a
word,
but
whether
when
they're,
comparing,
if
these
objects
are
the
same,
they
don't
use
those
optional.
Qualifiers,
they're
just
hints
that
humans
can
use,
or
whatever
intelligent
tools
can
use
to
try
to
deduce
that
these
are
the
same
thing.
E
I
E
E
Yeah
at
this
time
they
are
using
the
docker,
the
docker
strings
that
are
in
the
perl
spec
right
now,
but
that
is
assuming
that
you
know
docker
is
the
docker.
Is
the
tool
used
to
distribute
container
images
or
mess
with
container
images,
but
that's
the
whole
purpose
of
the
pearl
in
the
first
place
is
to
have
some
human
readable
way
of
understanding
the
semantics
rather
than
the
syntax.
E
J
Yeah,
in
that
case,
I
think
it
is
important
to
have
the
outer
media
type
like
if
a
tool
is
going
to
try
to
interact
with
this
thing.
It
needs
to
know
the
type
of
that
thing.
So
there's
an
important
difference
between
an
image
index
and
an
image
and
like
image
indexes,
aren't
only
used
for
multi-platform
images.
You
may
use
it
to
distribute
a
collection
of
images,
which
is,
I
think,
a
separate
thing
wholly
from
like
a
single
artifact
right.
J
D
D
You
know
the
fact
that
it
says
artifact
type
that
helps
you
know
it's
a
helm
chart
or
a
container
image.
That's
there's
no
code.
That's
going
to
directly
parse
that
it's
literally,
how
do
we
convey
what
this
pointer
is
pointing
to
in
a
human
readable
way
that
doesn't
have
to
rename
names
that
have
already
been
created,
you're,
saying
they're
only
going
to
pull
blobs.
D
What
we're
saying
is
the
ways
the
way
you
identify
things
in
a
registry
and
again
we're
using
things
because
for
some
reason,
artifacts
is
not
a
way
to
think
we
can
use
the
way
we
store.
Artifacts
in
a
registry
is
uniquely
identified
by
a
tag
which
is
mutable
or
a
digest,
which
is
immutable,
so
we're
saying
if
an
spdx
or
an
s-bomb,
because
I
don't
want
to
get
into
saying
spdx
and
cyclone
dx
every
time.
D
If
I
have
an
s-bomb,
you
want
to
make
sure
it's
uniquely
talking
about
one
and
only
one
thing:
it
doesn't
matter
what
registry
it's
in
and
that's
a
different
part.
It's.
How
do
I
say
this
thing
absolutely
points
to
this
one,
and
only
one
thing
that
today
is
the
digest
the
digest
of
the
manifest
and
then
through
the
manifest
it
goes
and
finds
the
blobs
and
does
all
the
detail,
whether
it's
the
repo
name,
whether
it's
the
what
else
with
the
architecture,
the
registry
url.
L
So
I
guess
the
question
I
was
going
to
throw
out.
There
is,
how
are
these
pearls
generated
and
then
how
are
they
used
and
specifically
on
the
type
fields?
I
think
that's
the
one
we've
been
churning
on?
Is
it
I'm,
assuming
there's
probably
going
to
be
some
automatic
generation
code
in
there?
Does
it
look
and
say
what
is
this
thing?
Is
it
an
image?
Is
it
an
abstract.
L
D
D
A
L
Yeah
except
they're,
I
think,
they're
taking
an
extra
step
farther
and
they're
looking
not
just
at
the
media
type
at
the
top
level,
but
also
the
artifact
type.
If
you
have
something
you
know
going
forward
when
we're
pushing
artifacts
the
aurora's
artifacts,
I
think
that
steve's
working
on,
I
think,
that's
what
we're
looking
at
well.
D
D
D
C
D
L
If,
if
we
work
to
that
logic,
then
I
think
you
know
just
documenting
it
down.
It
doesn't
even
need
to
be
in
the
spec
or
anything,
but
just
throwing
a
comment,
throw
it
somewhere
that
we
can
look
at
and
just
kind
of
go
back
and
forth
and
say:
okay,
this
makes
sense
for
how
we
look
up
the
type
and
it
may
come
out
saying
after
all
that
that
maybe
it
was
a
better
way
to
put
this
field
in
there.
Maybe
not.
I
Okay,
so
I
don't
think
we're
going
to
resolve
this
today.
I
do
want
to
figure
out
how
we're
going
to
decide
what
we're
gonna
do
moving
like
is
there
do
we
want
to
take?
I
don't
know
how
consensus
works
here,
but
eventually
we're
gonna
have
to
make
a
decision
about
how
we
wanna
do
this.
If
we
want
any
sort
of
movement
in
the
prospect,
so
I
don't
know,
though
it
seems,
I
think,
john.
I
If
I'm
understanding
your
wants
with
the
changes,
you
want
to
get
rid
of
oci
artifact
and
you
want
to
separate
out
the
artifact
type
of
media
type
or
get
rid
of
them
all
together,
and
then
that
would
work
for
you
or
like
what
to
try
and
understand
what
everybody
wants.
And
then
how
would
you
meet
in
the
middle.
J
J
J
C
D
C
J
C
J
I
I
D
I
Yeah,
I
think
we
all
just
need
to
keep
in
mind.
Some,
like
both
sides,
probably
are
gonna,
have
to
concede
a
little
bit
to.
We
have
an
ideal
way
of
how
we
want
it
done
we're
gonna
have
to
meet
in
the
middle
and
figure
out
a
way
to
move
this
forward,
and
so
I
mean
I
think
we
need
to
prepare
to
concede
slightly
on
one
side
or
the
other,
so
that
both
people
are
not
perfectly
happy
but
a
little
bit
happy.