►
From YouTube: OCI Weekly DIscussion - 2021-09-08
Description
Recording of the weekly OCI developer's call from 8 Sep 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-8-2021
A
B
B
A
B
D
B
A
A
E
E
But
in
order
to
do
that,
we
need
a
canonical
format
for
an
oci
artifact
package
url
and
what
the
spdx
specification
is
looking
for
is
a
string
that
represents
a
specific
container
or
or
oci
artifact
in
the
spx
document,
and
spdx
3.0
will
require
a
uri
and
to
satisfy
that
requirement.
We
can
use
pearl,
but
we
want
it
to
be
consistent
across
all
oci
artifacts
so
that
we
don't
have.
E
You
know
20
different
pearl
entries
for
20
different
types
of
oci
artifacts.
So
the
proposal
that
we
have
that
we'd
like
to
submit
to
the
pearl
specification
is
starts
where
it
says
oci
in
the
link
from
the
agenda,
and
I
can
also
drop
that
in
the
chat.
If
that's
easier
for
people
oh
looks
like
philary
did,
did
she
already
do
that?
E
E
So
the
name
of
the
oca
artifact
would
be
the
name
of
the
repository
and
then
the
version
is
the
sha-256
digest
of
the
artifact
and
then
there's
optional
qualifiers
that
you
can
use
to
describe
the
artifacts.
So
things
like
architecture,
repository
tag,
sub
paths,
and
then
we
outline
some
examples
of
what
that
might
look
like
for
different
types
of
artifacts.
E
B
B
B
A
That's
actually
exactly
the
goals,
it
was
it's
not
here.
We
were
initially
thinking
about
it,
consume
the
public
content
and
bring
it
into
the
private
registry
inside
you
know
some
environment
and
I
want
to
be
able
to
have
s-bombs
or
whatever
the
content
refers
to
those.
Well
in
case
it
is
s-bombs.
I
shouldn't
have
to
go
to
some
public
location
like
dockerhub
or
whatever,
but
it's
just
as
relevant
to
that
somebody
publishes
the
exact
same
content
on
docker
hub
on
ecr
public,
on
github
or
other
public
redistribution
registries.
A
G
I
guess
since
there's
a
gap
in
the
conversation
I'll
just
say,
instead
of
just
typing,
it
yeah
the
the
only
concern
with
taking
out
the
repo
and
registry
name
and
then
just
having
the
short
field.
Is
that
yeah?
You
get
the
confusion
when
you
have
two
different,
the
same
name
being
two
two
very
different
things
potentially,
and
so
the
company
goes
out
and
extends
java
and
puts
in
all
their
own
stuff
in
there,
and
it's
no
longer
anything
that
looks
like
open
jdk
upstream,
but
it
still
has
the
same
short
name.
G
E
E
G
B
B
E
B
H
A
That
would
be
a
great
piece
of
the
conversation
here.
We
were
struggling
a
little
bit
with
encoding
slashes,
the
full
name
space
is
version
and
important
like
if
that
was
the
chunk
we
wanted
to
chew
on
there's
some
great.
You
know
that
would
be
a
great
thing
to
say:
okay,
everything,
but
that
is
good
and
let's
just
figure
out
how
to
narrow
that
part
down.
H
I
think
so
it's
kind
of
weird
because,
like
we
have
two
systems
that
are
trying
to
abstract
over
each
other,
maybe
even
three
if
you
include
spdx,
and
so
it's
kind
of
like
trying
to
put
bags
inside
each
other-
and
it's
not
gonna
work
super
well.
The
things
I
think
are
important
from
like
an
oci
perspective
or
to
capture,
maybe
just
like
a
descriptor.
Can
we
put
all
the
descriptor
properties
of
something
in
like
these
optional
qualifiers,
like
yeah.
A
H
E
E
E
B
A
There's
a
no,
the
namespace
would
actually
be
whatever.
That
thing
is
it's
a
container
image.
It
would
be
oci
dot,
image,
vis-a-vis,
the
the
media,
type,
expansion
or
contraction.
So
assuming
we
decide
on
whatever
the
current
media
type
is
that
we
use
for
the
artifact
type
so
that
config.manifest.mediatype
or
manifest
config
media
type
or
artifact
type
in
the
manifest
spec.
The
the
point
is,
is
the
repo
and
the
digest
is
what
kind
of
ties
them
together.
So
there's
human
and
computer,
readable
human,
readable
and
computer
verifiable.
I
A
Just
the
last
piece
to
it
is
that
we
originally
would
originally
one
of
the
iterations
had
the
artifact
type
as
one
of
the
parameters.
You
know
the
optional
parameters
and
it
just
seemed
like.
Maybe
we
should
use
that
in
the
namespace
because
we're
it
looked
like
a
good
prop,
a
good
way
to
solve
that
problem.
I
So
I'm
trying
to
understand
this,
so
is
the
assumption
that
if
we
do
move
a
container
that
there's
going
to
be
some
intermediate
tool,
that's
actually
going
to
go
in
and
change
the
original
name
to
somewhere
else.
Because
wouldn't
it
be
confusing
to
move
an
image
from
one
registry
to
another
and
then
to
pull
it
and
have
that.
That
repository
be
just
something
totally
different.
B
Well,
either
that
or
if
you're
expecting
these,
I
guess
my
thing
is
more
that
if
you're
expecting
the
identity
of
this
thing
to
be
effectively
permanent,
you
know-
and
if
I
have,
if
I'm
the
owner
of
ebats
my
app
and
I
move
it
to
quay
and
one
day
in
the
future,
you
see
dr
ao
be
back
to
my
app
and
that
doesn't
exist
anymore.
You
know
where
I
was
like:
I've
migrated,
my
stuff
off.
B
B
Didn't
ideally
yeah,
that's
that's
where
I'm
trying
to
like
work
through
that
part
of
it
like
really
the
digest
is
key
and
if
it
just
happens
to
be
called
vbats,
my
app
or
on
docker
quiz.
You
see
it.
You
know
google
github
whatever,
then
that's
kind
of
beside
the
fact.
So
maybe
that's
my
app
or
if
it's
just
the
digest,
I
don't
know.
I
I
guess
an
issue
that
kind
of
comes
to
my
mind
is
like
let's
say
that
I
discover
a
container
lying
around
and
I
want
to
find
like
the
original
source,
and
it
has
some
registry
that
doesn't
exist
anymore.
It's
kind
of
like
a
useless
identifier.
It
becomes
like,
like
kind
of
I
think,
john
said
this,
like
you
could
just
put
anything
in
there
put
potatoes
and
whatever
like
it's
just
it's
just
not
it's
not
really
useful
for
anything.
I
A
I
mean:
do
you
need
the
the
idea?
Is
the
s
bomb,
the
combination
of
the
s-bomb
and
the
thing
like?
Does
it
you
may
or
may
not
care
where
the
original
thing
came
from?
It's
that's
why
it's
really
an
optional
hint.
The
thing
is
you
have
this
image,
you
have
an
s-bond
for
it.
The
assumption
is,
there's
some
signatures
around
it
that
ensure
its
integrity.
A
But
the
point
is:
is
that
between
the
combination
of
the
s-bomb-
and
you
have
this
thing-
you
have
a
way
to
decide
whether
you
want
to
use
it
move
forward,
whether
the
linkage
to
it
is
still
the
same.
It's
it's
kind
of
like
picking
up
the
usb
stick
off
the
street
right.
It's
like
there
may
actually
be
something
usable
in
there
or
it
may
not.
Maybe
that's
not.
E
There's
also
lots
of
other
context
around
what
this
artifact
is
in
the
spdx
document.
This
is
one
descriptor
in
the
spdx
document,
so
we're
this
is
not
like
the
only
way
that
we're
going
to
identify
an
oci
artifact
is
this
artifact
url.
This
is
just
giving
more
context
as
a
descriptor,
there's
other
other
things
that
are
describing
it
in
that
in
an
spx
document.
A
H
So
I'm
trying
to
understand
how
these
things
will
be
used
because,
like
if
people
are
just
going
to
compare
these
two
strings
without
really
thinking
about
it,
then
I
think
it's
a
terrible
idea
to
put
the
registry
anywhere.
If,
if
there's
like
parsing
mechanisms
that
tease
out
specific
things
they
want
to
compare,
then
I
wha
what
things
are
those.
H
Yeah,
so
the
repository
inside
this
name
slash
namespace
field
or
even
in
an
optional
qualifier,
to
have
the
registry
domain.
I
think
that's
how
the
docker
one
does
it
it.
I
guess
it
depends
on
how
this
is
going
to
be
used.
Like
are
people
going
to
compare
these
to
see
if
they're
the
same
thing,
and
if
so,
we
should
probably
avoid
any
urls
anywhere.
A
A
general
question,
because
this
has
come
up
a
lot
when
we
we
think
about
artifacts,
that
move
between
registries
and
so
forth.
What,
if
you
think
about
all
most
the
other
package
managers?
The
name
of
the
package
is
the
same
like
it
generally
doesn't
change
the
name
when
it
moves
across
and
it's
in
fact
you
do
an
npm
restore
of
a
package
name
and
you
separately,
configure
where
you
get
it
from.
A
What
position
do
we
want
to
suggest
is
the
I
don't
know
standard
guidance,
best
practice
spec
whatever,
so
that
an
alpine-
and
I
just
saw
alpine
is
an
alpine
image-
is
still
the
alpine
image
in
another
registry
and
you
can
technically
rename
it,
but
does
that
become
an
invalidator
to
it
being
the
same
thing,
I
I
struggle
with
it,
because
a
digest
is
great
for
computers,
but
you
still
need
in
most
cases.
You
need
to
know
where
to
look
for
that
digest
in
a
registry.
B
Yeah,
this
is
a
tricky,
tricky
problem
and
even
you
said
it
in
the
chat
earlier.
Isn't
this
kind
of
the
same
problem
that
you
have
with
package
managers-
and
this
is
like
age-old
debate
of
like
you,
know
I'll
package
this
for
rel
and
I
package
it
for
centos.
They
might
have
vastly
different
build
environments
so
just
because
they
come
out
with
the
same
bash,
5.1
they're,
not
the
same
thing.
B
Now
you
know
like
they,
they
might
have
very
similar
names.
You
end
up
having
to
have
like
an
ownership
of
that
name
space
so
like
in
your
example
like
alpine.
If
there
was
some
way
to
say
actually,
you
know
it's
embedded
in
there.
Some
kind
of
signature
of
like
a
thing
that
could
have
only
been
put
there
by
the
alpine
creators
or
something
like
that
and
anybody
that
packages
that
couldn't
have
tampered
with
this
validatable
signature
and
that's
just
not
a
problem.
Software
packages
have
solved
yet
so
whether
you
build.
B
G
G
A
Isn't
it
needed,
though
I
mean
the
digest,
is
the
way
to
assure
it's
unique
right
like
if
two
people
build
alpine,
you
know
the
between.
What's
in
the
s-bomb
and
the
contents
and
so
forth
and
the
signing,
but
more
importantly,
the
digest,
they
would
make
sure
that
you
wouldn't
get
an
unnecessarily
an
s-bomb
linked
to
the
wrong
one,
even
if
they
wound
up
being
loose
right,
because
the
digest
says
at
the
end
of
the
day
they
both
say
alpine,
but
if
they
have
different
digests.
Sorry.
I
Who
is
who
or
what
is
responsible
for
kind
of
maintaining
or
identifying
the
relationship
between
one
of
these
spdx
metadata
practices
whatever
and
then
the
image?
Because
I
mean
it's
kind
of
similar.
If
you
think
about
it,
what
we
have
in
registries,
we
have
like
manifest
blobs
and
we
don't
like
write
like
a
tag
anywhere
in
there.
You
know
explicitly
so
like
if
it's
the
fact
that,
like
a
registry,
for
example,
is
responsible
for
linking
like
one
of
these
spx
things,
the
the
pearl
to
to
like
the
image.
I
E
I
think
that
they
are
valuable
in
context
with
the
timestamp
that
the
document
was
created
and
they're
used
for
hints
to
humans,
they're
not
used
as
for
the
computers
to
compare
these
artifacts,
so
I
I
think
I
mean
I
I
see
value
in
them.
If
an
engineer
is
looking
through
this
spdx
document
and
is
looking
at
this
artifact,
they
can
see
the
timestamp
that
the
document
was
created
and
in
context
with
the
repository
url
or
the
tag
can
make.
E
You
know
assumptions
about
that.
I
think
we're
not
trying
to,
because
I
do
agree
with
you
that
they're
not
going
to
be
true
forever.
I
mean
this
is
the
internet
things
change
very
fast,
so
I
think
that
we
would
be
kidding
ourselves
to
think
that
we
could
find
a
way
to
create
this
artifact
url.
That
would
hold
forever,
and
I
think
it's
also
important
to
keep
in
mind
that
these
don't
need
to
be.
E
B
A
I
think
the
real
goal
is
because
the
big
conversation
we've
been
having
in
the
spdx
group
is
the
the
concept
of
uniqueness.
How
do
you
make
sure
we're
referencing
something
that's
unique
and
making
sure
that
the
property
names
that
have
uri
url
on
them?
Don't
suggest
that
you
have
to
go,
find
them
at
that
location?
A
That
says,
I
don't
know
how
I
got
disassembled
and
reassembled,
but
when
I'm
trying
to
verify
that,
I
have
an
spdx
for
this
thing
that
there's
a
piece
of
data
that
says
this
is
the
very
unique
identifier
and
the
digest
seemed
like
the
thing
to
do
that.
I
think
the
most
interesting
com
part
of
this
conversation,
which
should
the
digest
be
in
the
name.
A
If
that's
the
required
versus
version-
and
I
guess
I'd-
have
to
study
the
prospect
again
to
figure
out
how
important
is
the
fact
that
it
says
optional
to
really
do
the
thing,
because
for
any
one
of
these
the
idea
is
you
go,
read
this
entry
and
decide
for
a
debian
package.
This
is
how
I
compare
things
for
you
know
oci
content.
This
is
how
I
compare
a
thing.
That's
we're
trying
to
enable.
I
B
This
is
actually
a
very
similar
conundrum
that
we've
seen
in
the
past,
like
how
best
you
can
say
like
an
rpm,
is
actually
what
it
should
be
because
with
in
rel,
red
hat
and
otherwise
you
know
not
uncommon,
like
people
might
even
have
their
own
patch
to
bash
and
they
fetch
the
source.
Rpm
add
their
patch
rebuild
it,
and
so
it
shows
up
as
like.
Oh
it's,
the
pack.
You
know
it's
the
particular
version
of
bash
or
whatever,
but
to
go
back
and
say
that
it's
actually
not
the
same
same
one.
B
Is
it
the
one
that
we
support
or
not
the
one
we
support?
It
could
have
the
same
name
and
a
lot
of
these
same
things,
but
if
it's
in
this
situation
at
the
time
that
it
was
built,
you
know
you
look
back
at
this
kind
of
audit
log
at
the
station
trail
of
what
the
thing
you're
holding
you
know
the
image
or
whatever
you
look
at
the
spdx.
B
Did
you
want
to
say?
Oh
actually,
it
was
not
the
same
digested
the
image
that
I
thought
it
was
so
it
really.
It
would
be
like
the
required
piece
of
metadata
and
the
name.
The
name
and
registry
came
from
all
just
optional
because,
like
at
the
time
that
it
was
run
or
time
that
it
was
built,
the
digits
pdx
was
generated.
So
in
that
way
I
think
it's
fine
a
lot
of
those
things
to
say
it's
optional,
that's
really
the
digest
required,
name
or
otherwise.
E
E
E
B
E
A
Maybe
you've
looked
at
it.
Closer
is
version
so
optional
that
it's
irrelevant
like.
If
you
look
at
the
digest,
if
you
think
of
the
name
the
name
today,
you
know
vis-a-vis
that
you
can
rename
things
doesn't
mean
you
should,
but
that's
it.
You
know
separate
that
for
a
second,
the
name
is
the
is
the
name
of
the
thing
and
the
version
is
the
digest,
because
the
idea
is,
I
can
keep
on
pushing
things
to
the
same
repo
and
the
thing
that
makes
it
unique.
A
G
E
I
think
what
I
was
thinking
is
if,
if
it
is
optional,
and
so
somebody
because
the
version
is
really
the
only
thing
that
across
registries
and
repositories,
if
the
image
is
the
same,
like
identifies
two
identical
binaries
in
different
locations
as
being
the
same
right.
So
if,
if
those,
if
the
version
is
optional
and
someone
doesn't
put
it
in,
then
we
just
have
like
oci.
If
we
are
doing.
E
If
I'm
looking
at
this
first
example,
it'd
be
oci,
artifact,
slash,
oci,
dot,
image,
slash,
I
guess,
without
the
shot,
then
it's
there's
only
hints
around
it.
That
may
be
different
in
different
registries,
but
I
guess,
if
we're
not
trying
to
be
a
hundred
percent
in
comparing
these
things
equal,
then
it's
not
necessary.
It
just
feels
like
it's
strongly
encouraged
and
I
think
optional
doesn't
capture
the
emphasis
on
the
usefulness
of
it.
A
When
you
look
at
the
description
in
the
pearl
spec,
it
would
state
what
how
it's
used
for
this
type
like.
If
you
look
at
some
of
the
other
ones,
they
all
make
variations
on.
You
know
how
they
get
used
within
this
generic
spec,
like
how
does
if
we
compare
it
to
the
others.
Does
this
really
stand
out
so
unique
that
it?
It
feels
wrong.
A
No
sorry
the
with
this
proposed,
if
you
took
the
proposal
and
then
put
version
as
being
the
the
digest
and
name
being
the
repo
name,
and
we
basically
put
a
description
that
says
you
know
the
version.
While
the
prospect
says
it's
optional
for
this
particular
one,
it's
actually
required
to
figure
out
how
it's
unique.
A
E
Yeah,
I
think
that's
actually
something
we're
going
to
talk
about
at
the
spdx
doc
fest,
because
version
is
component
version
is
required
as
according
to
the
ntia
minimum
requirements
for
an
s
bomb,
and
so
there
is
a,
I
think,
there's
a
gap
there.
That
needs
to
be
addressed
because
I
agree
version.
If
you
just
have
a
name,
you
know
name
the
same
name,
but
different
versions
are
not
the
same
thing,
so
I
I
don't
know
enough
about
the
pearl
spec
to
know
whether
us
saying
you
know
this
is,
I
think
what
I?
E
A
So,
just
going
through
some
new
specs
that
try
to
make
the
base
spec
be
generic
and
flexible,
while
artifact
specifics
can
make
them
more
narrow
like
this
is
the
conversation
is
the
artifact
spec,
you
know
says:
blobs
are
not
required,
but
if
you
use
something
like
the
container
image,
you
can
say
for
this
use
of
it.
They
are
required.
A
I'm
wondering
if
that's
how
this
pearl
spec
is
being
used
to
say,
look,
there's
some
flexibility
in
how
perl
is
being
used
when
it's
being
used
in
the
spdx
scenario.
Version
is
required,
because
what
else
is
if
an
spdx
can't
target
a
specific
thing,
then
what's
the
purpose
of
the
the
s-bomb
yeah?
What's
the
integrity
of
the
s-bomb,
so
to
speak,.
E
B
It
it's
probably
worth
surfacing
as
a
conversation
topic,
but
I
would
yeah
hope
for
the
best
plans
for
the
worst.
They
say:
no,
it's
actually
going
to
be
optional
and
you
have
to
figure
out
another
way
to
bolt
it
on.
Then
you
know.
Maybe
we
just
used
overload
the
name
field
for
what
we've
just
discussed,
but
I
think
like
in
the
kind
of
larger
meta
conversation
like
you
said
that
you
know.
If
ntia
has
certain
requirements,
then
that
sounds
like
a
different
piece
to
be
wrapped
with.
B
E
H
E
H
But
so
I
I
don't
want
to
derail
this
too
much,
but
like
do
you
have
more
context
from
spdx's
side,
I
see
a
lot
of
links
to
like
pearl,
but
is
it
a
foregone
conclusion
that
they
want
to
use
pearl
for
this?
Yes,
because
it
seems
like
we're
kind
of
bending
over
backwards
to
fit
something
into
pearl,
that
it
wasn't
meant
to
do.
H
A
A
F
A
Oh
I'm
sorry
in
the
pearl,
there's
they've
got
basically
slashes
separate
out
whether
it's
a
name
space
or
a
name.
They
don't
actually
have
the
nested
namespace
content
concept.
So
if
you
had
separated
out
yeah,
so
if
you,
if
you
literally
put
the
literal
string
that
we
use
our
application,
slash
vmd,
that
slash
makes
it
look
like
application
is
the
name
space
and
then
vnd
is
the
name
which
is
obviously
not
what
we
want.
So
I
I
agree
with
you.
I'm
just
wondering:
do
we
encode
it
or
do.
H
H
A
E
H
F
H
H
A
E
F
A
A
Just
redoing
all
the
naming
thing
the
piece
so
rose.
What
does
like
I'm
looking
at
the
examples
for
debian
or
deb
and
others,
I
just
had
the
sense
that
the
namespace
was
required.
I
don't
think
you
can
actually
say
package,
colon,
oci,
artifacts,
slash
digest.
I
think
there
does
need
to
be
something
or
not
digest
but
slash
repo
repo
at
digest.
It
looks
like
we
do
need
something
in
between
and
I
thought
that's
how
we
wound
up
using
that
here.
Yes,.
F
E
A
A
A
E
E
E
A
C
C
A
I'm
watching
people
watching
my
squares
drop
off
quick,
brandon,
vincent
great,
perfect
conversation.
Can
you
queue
up
something
for
next
week?
I'll
put
the
template
in
now
for
next
week.
If
you
want
to
just
pop
the
agenda
item
in
there
and
if
there's
any
pre-reading,
then
folks
can
jump
on
from
a
from
a
facilitator
or
their
conversation.
That's
what
I
would
say
from
a
hey
I'd
love
to
figure
out
how
to
support
that
across
more
registries.
I
have
a
different
hat
that
I
would
wear
to
figure
out.
A
A
I
have
wanted
to
put
stuff
in
the
artifact
repo
to
say:
hey
here
are
all
the
media
types
and
by
the
way,
here's
some
localized
strings
and
icons.
You
can
use
to
say
what
they
are.
So
there
was
a
separate
angle
of
what
I
think
you're
asking
for,
but
the
last
comment
that
I
saw
in
the
artifacts
stuff
that
talked
about
this.
I
thought
I
put
a
comment
on
it
that
kind
of
framed
that
reframed
it.
So
I
look
I'm
happy
to
have
a
conversation
for
next
week.
Yeah.
We
just
need
to
merge
some
viewers.
A
A
B
Yeah,
it's
unfortunate
I'd.
I
have
shelved
any
any
in
all
of
my
hopes
for
travel
for
this
fall.
So
I
really,
I
think
I
got
my
hopes
up
a
lot
to
go
to
kubecon
the
oss
summit
up
in
seattle,
but
I
don't
think
it's
irresponsible
at
this
point.
There's
too
many
people's
lives
being
disrupted
by
the
delta
grain,
so
I
registered
for
the
oci
summit
to
be
virtual,
but
that's
not
nearly
what
I
was
hoping
for.
So.
A
I
think
we're
all
feeling
various
forms
of
what
you're
saying
at
least
virtual
is
better
than
nothing.
So
for
me,
I
don't
have
to
physically
travel
in
a
plane,
but
I'm
I
I
am
considering
the
kubecon
conversation,
but
the
point
is,
the
event
should
still
go
on.
I
think
is
the
plan
and
it'll
account
for
virtual
and
anybody
that
does
come
online,
but
anybody
that
does
come
in
person.