►
From YouTube: OCI Weekly Discussion - 2023-03-30
A
B
C
Right
first
thing:
I
had
on
the
list
up
here.
We
can
kick
it
off
and
go
with
the
simple
one.
First
and
then
we
can
get
into
anything.
More
complicated
later
on
is
the
1042.,
which
that
one,
it's
doing
a
couple
small
knits
and
tweaks
like
we
got
rid
of
the
scratch
descriptor
function
and
turn
into
a
couple
variables
previously
and
so
I'm
just
documenting
what
those
variables
were
instead
of
the
function
that
no
longer
exist
and
I
also
end
up
renaming
it
variable
in
there
I'll
get
to
that
in
a
second.
C
C
That
was
a
one
of
the
linters
triggered
on
this
one.
So
that
was
a
tweaked
attitude
to
get
the
CI
to
pass
just
had
to
drop
a
free
money.
We
weren't
using
it
so
I
decided
to
drop
the
variable
name
there
and
then
the
rephrasing
I
did
was
to
say
instead
of
scratch,
digest
data.
It's
just
scratch
data,
there's
no
digestion
here.
So
that
was
the
other
small
detail.
I
changed
so
I
was
hoping.
E
B
C
My
feeling
guessing
where
you
want
to
go
with
that,
to
be
able
to
pass
something
without
anything
some
of
that
goes
into
the
next
one.
We're
talking
about
artifacts,
the
the
other
part
of
it
that
I'll
push
for,
is
to
say
that
eventually
we
want
to
have
a
different
manifest
for
artifacts
at
some
point,
we're
it's
just
going
to
take
a
while
to
get
there.
B
F
E
Don't
want
to
add
a
conformance
to
validate
that
the
layers
are
present,
because
we
don't
have
that
because
that
would
break
conformance
and
it
could
mean
that
implementation
should-
or
at
least
they
should
ex
I
mean
they
can.
They
will
expect
a
layer
on
there
right
now,
no
implementation,
or
at
least
a
bunch
of
places,
don't
actually
enforce
that.
So
putting
this
would
actually
cause
it
to
create
confusion
in
those
places.
What
I'm
more
concerned
about.
C
E
A
B
C
E
There
and
that's
because
of
the
schema
that
we
kind
of
like
followed
along
I,
probably
wouldn't
were
to
people
who
historically
made
that
changed
into
what
direction
they
wanted
to
lean.
The
point
is:
I.
Don't
want
this,
my
My
Hope
Is
that
distribution
doesn't
have
to
validate
this,
because
this
is
now
a
must
on
the
specification
language.
E
C
G
G
E
Currently
There
Are
Places,
which
doesn't
reject
the
Manifest,
and
there
are
usage
of
scratch
images
in
places
which
doesn't
have
layers
so
adding.
This
would
indicate
that
those
are
invalid.
We've
kind
of
gone
down
the
path
of
trying
to
avoid
things
that
exist
as
being
invalid
by
changing
the
specification
of
1.1.
E
F
So
this
yeah,
the
question
here
is
basically
like
did
we
do
we
want
to
codify
what
some
1.0
Registries
already
imply
and
by
imply
I
mean
like
we'll
fail?
If
there
isn't
at
least
one
we
want
us
thinking
about,
codifying
it,
and
but
the
must
is
very
restrictive.
So
maybe
we
should
not
do
that
right.
I
do
think
you
like
kind
of
leave.
It
leaves
that
door
open
right,
like
like
a
brand,
isn't
basically
back
to
ambiguous
right.
G
H
H
H
C
C
This
is
one
we
agreed
to
last
week,
which
was
we're
adding
a
new
artifact
to
the
image
manifest
new
artifact
field,
I
cut
and
paste
a
bunch
of
text
around
that
and,
let's
see,
I
included
the
guidelines
for
a
usage,
so
I
kind
of
have
a
little
rough
guideline.
Slash
example:
usage
down
below
I,
then
add
a
new
media
type
oci
scratch
V1,
for
whenever
we
use
the
scratch
digest.
C
So,
instead
of
having
it
to
be
any
arbitrary
sample,
string
I'm
putting
it
to
a
very
specific
string
now
and
that's
only
when
we
have
the
scratch.
So
that
way,
if
you're
reading
a
scratch-
and
you
see
that
you
know
that's
effectively
a
nil
and
that
doesn't
exist
and
then
in
the
guidelines,
I
have
several
examples
here.
So.
C
The
second
example
here
is
when
they
don't
have
a
config,
so
this
is
say,
for
example,
you're
uploading,
an
s-bomb.
All
you
have
is
an
eotype
for
whatever
that
s-bomb
is
that's
going
to
go
over
here,
you're
going
to
have
the
scratch
for
the
config
more
than
likely
the
media
type
for
that
s
bomb
is
going
to
be
your
artifact
type
as
well.
C
Unless
they've
got
some
dedicated,
artifact
type,
they
want
to
pass
and
then
the
last
one
was.
If
you
just
want
to
upload
some
annotations,
you
don't
have
anything
else
in
there.
You
don't
have
a
layer,
you
don't
have
a
config
or
if
there's
our
scratch,
you
should
still.
No,
you
must
still
have
an
artifact
type
in
there
and
that's
how
you
can
pass
that
the
must
on
the
artifact
type
I
put
that
up
above.
C
B
D
A
G
C
So
that
was
the
order
of
operations.
I
was
thinking
of
phrasing
that
I'm
more
than
happy
for
someone
to
say,
here's
better
wording
than
what
I
was
saying
here
to
make
it
read
a
lot
easier,
but
that
was
the
goal
of
saying
we're:
building
reverse
response,
pull
the
artifact
height
first
and
fall
back
when
that's
not
defined
to
doing
the
config
need
type.
C
D
E
C
D
I,
don't
have
I
mean
we
can
we
can
discuss
stuff
about
archiving
artifacts.
The
current
state
is
that
issue
was
basically
the
artifacts
repo.
It
is
as
it
currently
exists
is
confusing
to
folks,
as
the
term
artifacts
is
confusing
to
a
bunch
of
folks,
and
we
should
I
think
it
says,
delete
the
repo
I
think
we
should
archive
it
with
a
note
at
the
top
that
says,
current
guidance
is
over
there
in
image
stack,
but
I
think
that,
basically,
the
work
we're
doing
will
be
necessary
to
do
that.
D
All
of
all
Brandon's
PRS
will
be
necessary
to
make
that
state
possible,
and
then
we
can
hand
it
over
and
start
the
Tob
voting
process
which
I
don't
I,
don't
know
how
or
what
timeline
that
will
be
on,
but
when
to
be
gets
the
question
they
can
ask
us
for
more
for
more
feedback,
I
suppose
but
I
think
in
general.
If
anyone
here
disagrees
that
that
we
should
get
rid
of
the
artifacts
repo
and
archive
it
speak
and
we'll
discuss.
I
I
I'm,
not
saying
the
artifacts
repo
is
a
place
to
go
but
like
when
I
envisions,
our
working
group
process
I
think
we
had
I,
don't
know
if
we
had
the
end
of
the
working
group
kind
of
defined
very
well,
especially
for
the
references
type
like
we
got
the
references
stuff
done,
and
then
this
like
artifact
stuff
kind
of
like
squeaked
in
and
then
got
kicked
out
so
I
I
think
we
do
need
to
discuss
at
the
Tob
level.
What
the
like,
where
this
work's
gonna
go
like.
I
Is
it
going
to
go
back
to
a
working
group?
Is
it
just
going
to
be
thrown
off
just
no
longer
no
CI?
Does
it
need
to
go
out
debate
personally,
I
think
that
the
artifacts,
probably
shouldn't
have
been
in
the
references
group
and
or
the
references
working
group
in
the
first
place,
I
think
it
warrants
its
own
working
group
and
it
can
be
kind
of
decided
or
kicked
out
at
that
point,
but
I
think
it's
good
to
have
like
some
continuation
of
that
discussion.
I
So
it's
not
just
seen
as
like
end
and
out,
but
yeah
I,
I.
Think
from
my
perspective,
what
the
outcome
of
that
should
be.
Is
we
have
a
working
group
to
discuss
artifacts
we
archive
that
repo
and
then
we
kind
of
if,
if
the
output
of
the
working
group
is
a
new
repo,
I
think
it'd
probably
be
a
new
repo,
not
a
continuation
of
that
one,
but
I
just
think
it'd
be
good
to
have
some
at
least
continuation
of
that
work.
I
D
D
It
should
be
subsumed
into
image
spec,
where
I
think
it's
more
authoritative
and
more
sort
of
official
and
making
finger
quotes,
but
you
can't
see
them
and
yeah
I
mean
if
future
artifacts
work
is
happening,
I'm,
fine
having
it
in
a
new
repo
or
in
this
repo
revitalized
to
be
about
that
work,
but
I
think
it's.
It's
been
a
constant
source
of
confusion
for
folks,
basically,
anytime
I
see
a
link
to
this
repo
I
know
that
someone
is
about
to
have
the
wrong
idea
about
what
artifacts
are
so
yeah.
G
C
I
want
to
separate
the
effort
to
make
a
new
artifact
manifest
where
I
think
there's
still
a
goal
to
create
that
eventually
And
archiving
this
repo,
because
this
artifacts
repo
was
just
saying,
here's
how
you
use
the
image
manifest
to
package
an
artifact
in
a
wrap
it
and
ship
it.
So
I
wasn't
talking
at
all
about
the
new
artifact
manifest,
so
I
want
to
make
sure
that
we
split
those
two
conversations
into
two
separate
things
and
I
think
there's
still
some
progress.
We
want
to
make
in
making
the
new
artifact
manifest.
C
But
for
this
one
to
say
we're
archiving
this
one.
It's
just
to
say
that
hey
we've
put
a
bunch
of
details
about
the
image
manifest
using
it
to
wrap
an
artifact
itself
that
we've
gotten
over
into
the
image,
spec
and
so
I
feel,
like
I,
agree
with
Jason
that
we're
right
about
the
point
we
can
archive
this.
D
D
Spec
much
of
this
guidance
is
on
its
way
over,
like
you
know,
a
single,
a
single
like
paragraph
in
a
thing
at
the
top
of
the
readme,
because
you
know
we
don't
have
to
Archive
it,
but
every
day
that
it's
there,
someone
will
reference
it
as
if
it
is
authoritative
and
up
to
date,
and
it
is
not
authoritative
or
up
to
date.
So
that's
my
only
urgency.
G
I
I
completely
agree
with
that.
I
think
my
my
preferred
sort
of
proposal
would
be
1.1.
Release
make
a
PR
to
artifacts
repo,
updating
the
guidance
here
and
pointing
to
oci
1.1,
but
not
archive
it
at
that
point,
because
I
think
that
sort
of
that
would
suggest,
for
example,
archiving
prevents
any
additional
PRS
being
made
against
it,
which
I
think
is
potentially
not
what
we
want.
If
we
need
to
update
the
guidance
in
the
future
or
say
another
working
group
spins
up,
we
might
want
to
have
this
be
a
pointer
to
it.
G
D
Yeah,
that
makes
sense,
I
mean
We've.
We've
walked
back
from
delete
this
repo
to
Archive
this
repo
and
I'm.
Fine
walking
back
to
you
know
replace
it
as
a
living
pointer
to
update
up-to-date
advice
and
image
spec,
mainly
the
the
goal
is
to
reduce
confusion
caused
by
this
repos
existence
and
incompatibility
with
up-to-date
advice,
so
I'm
I'm
perfectly
happy
with
that.
G
D
Think
I
would
prefer
that
to
live
in
the
image
spec
repo,
though
I
completely
agree
about
there
being
a
value
to
like
a
human,
a
human
language,
not
spec
language,
but
human
language
guide
to
how
to
do
this
and
some
examples,
I
think
if
we
can
put
things
in
the
spec
that
is
even
better,
but
for
things
that
are
more
like
between
you
and
me
with
that
without
the
spec
maintainers
here
you
should
really
use
this
kind
of
string
yeah.
That
seems
valuable.
I.
C
Yeah
we've
got
Derek
on
the
call
here
so
at
least
have
one
representative,
but
otherwise
I
was
going
to
say
that
we
probably
want
to
defer
the
maintainers
of
this
project
first
and
then
only
if
that
is
infeasible
should
we
bring
that
up
to
the
trb
or
only
if
we're
going
to
completely
sunset.
This
thing.
D
D
I
Go
ahead:
yeah
I
was
just
going
to
point
out
that
this
re,
the
reason
was
this
was
created
in
the
first
place,
was
because
we
wanted
to
pull
this
language
out
of
the
distribution
spec.
If
the
image
spec
wants
to
take
it
I
mean
that's
that's
great,
but
yeah.
We
just
wanted
to
pull
some
of
this
stuff
out.
I,
don't
know
whether
it's
living
or
archived
like
I,
don't
know
if
it
makes
too
much
of
a
difference.
I
I'm
not
sure
what
value
the
community
is
getting
from
from
some
of
the
specific
guidance,
or
at
least
some
of
the
specific,
like
pointers
at
the
different
types
but
yeah
I'm,
I'm,
I'm,
fine,
either
way.
I
just
want
to
make
sure
that
you
know,
there's
a
continuation
of
that
conversations.
We
don't
have
to
have
it
again.
I
D
That
would
be
great.
That
would
be.
That
would
be
totally
fine
by
me
not
that
I'm
trying
to
like
slip
anything
past.
The
Tob,
many
of
the
people
I
would
be
slipping
past
are
already
in
this
meeting,
but
the
process
of
getting
Tob
to
convene
to
make
a
vote
is
has
been,
has
been
difficult,
so
yeah.
If,
if
you
think
this
just
requires
a
artifact
maintainer
approval,
then
great.
C
G
I
would
love
to
rebase
my
PR
1030
once
you
merge
yours
and
get
a
review,
but
I
think
no
review
comments
have
been
made
yet
and
I've
I've
raised
it
in
the
past
three
or
four
calls
so
I
would
I
would
love
some
feedback
on
clarifying
that
additional
media
types
are
accepted,
for
example
the
artifact
media
type.
We
can't
like
have
an
allow
list.
C
G
C
I'll
phrase
it
differently:
it's
allowed
for
a
registry
and
I
have
the
tag
API
and
still
pass
a
bunch
of
the
oci
requirement.
You
know,
because
we're
only
testing
specific
apis
and
you
can
turn
off
on
and
off
individual
things.
You
want
to
not
check
on
your
registry,
so
it's
a
lot
of
what
we've
said
elsewhere
in
the
definition
of
the
spec
is
saying:
if
you
support
this,
here's
the
Response
Code
you're
supposed
to
get
back.
C
If
you
don't,
and
we
give
that
definition,
you
know
it's
possible
to
have
a
read-only
registry,
it's
possible
to
have
a
registry
that
only
accepts
those
CI.
Media
types
doesn't
even
accept
the
docker
media
types
and
so
to
to
say
that
we're
putting
a
hard
limit
in
here
that
you're
not
oci
compliant.
If
you
don't
allow
any
value
in
certain
fields-
and
we
know
that
Registries
today
are
limiting
that.
It
gets
me
nervous.
G
So
I
think
this
goes
to
I
would
love
a
review
of
the
pr,
because
the
precise
language
is
that
unknown
media
types
should
not
be
prohibited.
So
a
known
media
type
such
as
registry
saying
that
they
want
to
ensure
that
all
new
manifests
are
using
oci
instead
of
Docker
media
types,
for
example,
for
images
that
would
be
permitted
by
the
language
and
I
think
that
goes
to
I
think
the
need
to
have
a
review
again
I'm,
just
raising
that
this
PR
has
been
there
and
I've
raised
it
for
three
sessions.
B
E
1026
also
has
a
very
similar
strong
language,
like
implementation
must
support
any
media
type,
whereas
at
the
bottom
portability
kind
of
like
says
should
this
is
also
similar
to
how
we
kind
of
like
spoke
about
an
array
must
include
something
clarifying
anything
that
changes.
The
Stance
of
from
ambiguous
to
any
kind
of
forced
implementation
will
invalidate
a
bunch
of
folks
and
I.
E
G
I
think
that
without
language
in
this
aspect
that
actually
specifies
that
non-image
content
has
to
be
accepted
in
some
form,
then
it
is
completely
compliant,
and
this
goes
to
sort
of
the
portability
concerns
right.
If
we're
talking
about
Brandon,
you
talked
about
ensuring
that
your
implementations,
that
might
be
behind
an
air
gap
or
might
be
in
an
Enterprise
situation,
where
they
update
very
slowly,
that
if
you
cannot
actually
attach
an
s-bomb,
cannot
upload
an
s-bomb
cannot
upload
an
attestation
cannot
upload
cat
gifs.
G
You
know
whatever
sort
of
media
you're
trying
to
copy
from
an
upstream
or
out
external
registry,
this
potentially
fractures
the
ecosystem
in
that
registry,
a
May
set
a
hard
limit
on.
We
will
have
an
allow
list,
and
what
I'm
trying
to
suggest
is
that
it
would
be
very
beneficial
for
oci
as
a
specification
to
say
we
don't
specif,
we
don't
permit
Registries
to
specify
allow
list.
G
A
block
list
is
okay
right,
like
don't
permit
Docker
media
types,
for
example,
and
that
would
be
some
sort
of
advertised
functionality
of
the
registry,
but
you're
not
going
to
have
portability
of
the
types
of
artifacts
that
people
are
describing.
Unless
you
satisfy
it
in
the
spec
somewhere
and
the
the
language
in
this
and
I've
rebased,
my
tier
actually
on
top
of
yours,
so
there's
two
commits
now,
but
the
second
commit
just
contains
the
changing.
Some
of
the
error.
G
C
E
Yeah
1026
was
the
that
was
the
only
one
right.
Yes,
I'm
I'm
a
little
torn
with
that,
because
this
would
mean
that
anybody
who
doesn't
accept
every
possible
config
media
type
is
non-conformant
but
with
artifact
type
being
in
the
Manifest.
Maybe
that's
the
loose
feel
that
people
can
play
with
rather
than
the
config
media
type.
C
C
E
E
C
Yeah,
the
the
challenge
that
I
run
into
is
that
I
definitely
see
where
you're,
where
you're
going
with
what
you're
trying
to
do.
Aaron
and
and
I'm
there
with
you
I
want
to
see
this
happen,
but
I
also
am
trying
to
balance
making
sure
that
we
don't
put
so
many
restrictions
in
there
that
nobody
has
no
CI
compatible
registry
and
therefore,
if
the
validation
there
becomes
meaningless,
because
there
is
none
out
there
to
look
at.
C
C
G
Yeah
and
and
again
any
oci
1.0
compatible
registry
must
because
artifact
type
is
not
defined
on
image.
Manifest
must
accept
any
arbitrary
artifact
type
today,
so
we
don't
risk
any
breaking
any
current
implementations
requiring
that
implementations
must
accept
unknown
media
types
and
and
I
think
the
the
word
unknown.
There
is
intended
to
indicate
that
you
may
specify
a
block
list
if
there,
if
there's
some
sort
of
malicious
content
or
some
sort
of
bad
actor
in
the
ecosystem,
then
of
course
they
can.
They
can
take
action.