►
From YouTube: OCI Weekly Discussion - 2023-03-16
B
D
D
E
All
right,
I
have
a
fun
one
and
I
mean
that
in
the
not
sarcastic
way
talking
to
a
couple
of
folks,
John
and
Josh
and
Matt
on
our
side,
we
were
talking
about
the
usefulness
of
being
able
for
a
registry
to
communicate.
E
Non-Blocking
warnings
basically
like
oci,
should
not
specify
what
These
Warnings
are,
but
example,
warnings
that
a
registry
might
want
to
tell
a
client
is
this
image
is
deprecated.
This
image
will
change
its
Behavior
soon.
Your
token
is
about
to
expire
today
is
Tuesday
and
the
weather
is
nice,
whatever
whatever
we
want
to
say.
E
We
can't
put
this
obviously
in
the
body
of
the
response,
but
we
can
put
these
in
headers
and
I
learned
last
week
that
there
is
an
well.
It
was
a
real
roller
coaster.
There
is
an
official
HTTP
warning
header,
please
use
registry
decades
instead
of
the
other
thing
yeah
exactly
that.
Would
that
would
be
an
excellent
thing
to
step
into
a
warning.
There
is
an
official
HTTP
warning
header.
E
It
was
deprecated
at
some
point
in
the
past,
but
kubernetes
still
uses
it
recently
over
the
last
two
years
added
the
ability
to
specify
warnings
coming
back
from
the
API
server.
So
even
though
it's
officially
deprecated
I
think
we
should
follow
kubernetes
precedent
and
do
what
they
do
with
with
basically
exactly
the
semantics
and
restrictions
that
they
put
in
place
so
that
Registries
can
specify
these
or
can
can
communicate
these
things
out
of
Band
of
the
body.
E
Clients
should
I
think
we
can
talk
about
wording,
but
clients
should
bubble
these
up
to
users
in
some
way.
That
is
not
obtrusive
and
sort
of
leave
it
at
that
I
think
it's
a
relatively
small
diff
if
we
can
all
agree
on
the
wording
but
and
and
Brandon.
Thank
you.
You
had
a
couple
of
really
good
comments
about
like
what
do
we
do
when
there's
too
many
of
these
or
what
do
we
do
when
there's
a
bunch
of
requests-
and
they
all
say
the
same
thing
that
I
think
is
a
like.
E
A
lot
of
things
will
be
the
same
as
kubernetes,
and
a
lot
of
things
will
be
different
from
kubernetes.
Specifically,
we
don't
control
the
main
client
of
it
and
kubernetes
says
like
we
control
Coop
control.
We
can
change
the
behavior
of
that
very
easily.
E
There
are
a
lot
of
situations
where,
where
you
will
hit
the
registry,
you
know
eight
times
to
get
a
single
image
and
the
client
should
not
spam.
You
with
eight
identical
warning
messages.
Unless
it's
really
serious
about
this,
so
yeah
I
think
that
was
a
good
example
and
a
good
thing
to
sort
of
walk
through
I
think
we
can
say,
clients
should
do
it
in
an
unobtrusive
Manner
and
leave
it
up
to
the
client
to
decide
what
I'm,
what
unobtrusive
means
to
them.
E
They
can
even
ignore
it.
You
know
up
to
once
every
10
minutes
or
something
like
never
show
it
more
than
once.
Every
10
minutes,
let
alone
or
regardless
of
how
many
requests
get
made
in
that
10
minutes
or
something.
But
it's
sort
of
a
nice
compromise
that
we
don't
have
to
specify
exactly
what
unobtrusive
means
clients
can
make
that
up.
But
we
should
say
you
know,
take
care
not
to
be
spammy
and
gross.
E
What
do
folks
think
I
mean
I
know
we
have
the
usual
problem
of
not
having
maintainers
enough
to
to
ratify
it,
but
I
think
we
have
enough
to
at
least
get
this
PR
like
get
APR
merged.
If
we
think
this
is
a
good
idea.
F
E
I
don't
actually
know
the
details
of
the
deprecation
header,
but
I
think
the
warning
header
is
a
oh,
an
HTTP,
deprecation
header,
okay,
I
will
read
through
this
and
and
add
it
as
a
reference
it
in
the
proposal.
I
think
in
general,
I
want
to
I
want
to
do
whatever
kubernetes
does.
They
are
using
the
specific
case
they
wanted
to
use
warnings
for
was
for
deprecated
apis.
You
know
you're
using
batch
V1
beta1.
You
should
be
using
batch
V1
in
the
next
release.
E
This
will
go
away,
so
I
think
you
know
there
may
be
more
semantically,
correct,
headers
that
we
could
use,
but
I
would
rather
draft
off
of
kubernetes
decisions
rather
than
make
any
new
decisions
myself,
but
I
will
definitely
read
up
on
this.
I
did
not
know
about
this,
so
maybe
I'm,
maybe
I'll,
learn
something.
C
Without
reading
up
on
it
myself,
my
knee
jerk
reaction
is
the
deprecation:
has
a
different
connotation
than
a
warning.
A
warning
might
be
hey.
Your
password's
about
to
expire
deprecation
might
be
you're
using
a
functionality.
It's
going
to
go
away
in
the
future.
E
E
You
are
calling
to
the
registry,
you
know
you,
you
sent
us
something
we
will
accept,
but
we
would
like
you
to
send
it
differently
next
time,
so
I
think
that's
I,
don't
know
that
that
helps
answer
the
question
but,
like
I,
think
we
could
use
warnings
for
both
warnings
for
the
image
you're
pulling
is
weird
in
some
way
and
the
request
you
sent
me
is
deprecated
in
some
way.
F
E
C
D
C
C
C
So
a
few
things
in
this
PR
that
I
added
and
two
of
them
think
or
non-confrontational.
C
One
of
them
is
saying:
hey
for
the
scratch:
descriptor
I
just
changed
from
scratch:
descriptor
there
to
study,
scratch,
digest
and
scratch
data
just
use
the
right
terms,
because
we
got
rid
of
that
function.
So
I'm,
hoping
that's
pretty
straightforward.
I
also
put
the
end
of
this.
In
this
other
file,
I
renamed
the
field.
We
have
scratch,
digest
data
I'm
thinking.
Well,
it's
not
really
a
digest.
It's
just
the
day
itself.
So
I
was
renaming
the
scratch
data
and
I
put
a
comment.
So
hopefully
that's
pretty
straightforward
too
between
those
two.
C
C
Talking
about
all
these
file
system,
layouts
and
all
those
fields.
I
said
all
this
verbiage
here
doesn't
apply
we're
talking
about
an
artifact.
It
only
really
applies
we're
talking
about
an
image,
and
so
I
moved
all
of
that,
with
the
exception
that
you
have
to
have
at
least
one
entry
just
because
I
feel
like
there
are
at
least
some
places
verifying
that
that's
what
we
saw
in
our
checks.
C
C
C
So
the
the
last
one
here
that
probably
will
cause
trauma
and
say
the
best
for
last
is
that
we've
got
a
bunch
of
layers
in
there
and
we've
got
some
descriptions
of
places
of
what
a
scratch
digest
is.
So
we
add
elsewhere
and
so
I
said,
let's
have
the
guidance
for
the
artifact
usage,
just
kind
of
give
people
an
idea
of
how
they
can
use
this
when
they
start
to
deploy
it,
and
so
he
described.
C
C
C
C
C
This
is
when
we
get
into
the
part
that
people
get
less
comfortable
with,
which
is
that
this
thing
we're
pointing
to
the
four
four
one
digest
in
there.
The
double
curly
brackets
is
no
longer
what
this
media
type
is
and
I
think
that's
where
people
get
a
little
paranoid,
and
so
I
wanted
to
put
that
out
there
and
if
we
say
yeah,
it's
not
the
same
thing.
We
didn't
need
to
be
the
same
thing.
Then
great.
Let's
go
ahead
and
move
forward
with
this.
C
In
this
case,
the
second
media
type
in
here
was
the
main
type
of
whatever
we'd
upload,
and
so
it
has
its
own
digest
all
estate
and
everything
else,
I
think
that's
kind
of
straightforward
and
then
the
last
example
that
people
are
asking
for
was
how
do
we
push
something
without
any
layers
at
all
and
so
I?
Just
we
Define
that
in
our
fact
find
that
we
did
and
we
just
had
the
same
digest
in
both
both
these
like
Curly
brackets.
C
C
C
D
C
G
What
what
artifact
type
the
artifact
type
of
this
manifest
is
Cyclone,
DX,
plus
XML
right.
We
could
resolve
the
confusion
around
this
by
just
not
setting
the
artifact
typed
application,
Cyclone,
DX,
plus
XML
right.
C
G
I
mean
so
like
if
we're.
If
the
problem
is
that
this
pattern
doesn't
work,
because
the
semantics
are
wrong.
G
C
C
C
G
G
G
C
G
G
But
so
I
mean
you're
writing
a
client
right.
That
is
like
looking
for
a
specific
thing
and
someone
is
passing
into
that.
A
cyclone
DX
plus
XML
media
type,
where
you
get
that
seems
out
of
and
right
so
can.
Can
we
Supply
a
different
media
type
than
Cyclone
DX
plus
XML
for
filtering
artifact
type,
and
can
that
media
type
be
correct.
F
I'm
kind
of
inclined
to
agree
with
John
here,
I
think
applications
like
Cyclone
DX
would
have
been
the
artifact
type.
That
I
chose
the
the
encoding
of
the
fact
that
it's
XML
would
be
the
layer,
media
type
or
something
else
that
is
tool.
Specific
I
mean
that
this
is
guidance
in
the
end
of
how
they
want
to
do
it.
So.
C
Sure,
but
even
if
I
change
this
for
say,
Cyclone,
DX
and
Cyclone
DX
has
multiple
kinds
of
formats.
If
we
had
a
cat
picture
and
it's
a
gif
there's
no
Json
formatted,
GIF
I,
don't
think
well,
someone
will
probably
try
it,
but
I.
G
I
mean
so
like
whoever
is
packaging.
This
as
an
oci
artifact,
can
choose
an
arbitrary
string
and
that
arbitrary
string
can
be
communicated
to
clients.
That
is
my
understanding
of
how
artifact
type
works.
So
I
don't
see
like
if
it
is
a
problem
that
the
arbitrary
string
is
is
wrong,
as
in
you
know,
is
not
saying
it's
Json
where
Registries
and
clients
expect
Json,
then
I
think
the
people
who
are
packaging.
This
as
an
OC
artifact,
should
choose
a
different,
arbitrary
string
that
doesn't
upset
people.
G
D
G
The
single
layers,
media
type,
probably
and
then
I,
don't
have
to
come
up
with
an
arbitrary
string
to
represent
this.
But
where
you
know,
cats
already
out
of
the
bag
but
like
you
could
do
something
really
stupid,
like
plus
Json.
At
the
end
of
that,
then
satisfy
someone
probably
or.
G
A
Yeah
so
I
I'm
trying
to
understand
so
Brandon.
Are
you
saying
that
we
should
have
the
media
type
the
same
as
the
layer
type
or
because
I
agree
with
John
and
actually
I
had
a
conversation
yesterday
with
TV
folks
right
and
we
were
trying
to
to
figure
out?
For
example,
how
can
we
say
it
vulnerability
report,
which
is
sarif
vulnerability,
report
and
Link
it
to
the
image
that
they
started?
A
Vulnerability
report
belongs
to
right
and
I
was
using
like
the
the
Ayana
type
for
sarif,
but
trivi
folks,
say
well
tariff
doesn't
always
mean
a
vulnerability
report.
We
need
to
put
something
else
in
the
artifact
type
and
they
were
asking.
So
what?
What
is
the
else
thing
that
we're
gonna
put
there
right
and
filter
by
when
we
call
the
refers
API
and
with
like
we
said
we'll
put
as
John
said
arbitrary
string
right
now,
because
they
would
like
to
uniquely
identify
that.
A
But
then
the
next
question
came
and
it's
like
okay.
So
if
we
put
something
like
vnd,
3D,
blah
blah
blah
and
other
scanner
actually
understand
that
or
does
every
scanner
will
put
their
own
thing,
because
our
idea
is
that
I
generate
the
sorry
vulnerability
Report
with
trivi
and
I
can
read
it
with
I,
don't
know
quality
so
something
else
right.
C
C
A
C
The
phrasing
that
I
was
trying
to
use
was
to
say
whenever
we
saw
this
441
the
scratch
descriptor
whenever
you
saw
that
digest
in
there
you
just
assumed
this
was
a
null
that
this
media
type
is
point
to
an
all.
Here.
It
doesn't
really
point
to
actual
data,
and
so
it's
not
referencing
whatever
this
data
is
because
it's
0.21
all
at
that
point.
H
Yeah
I
think
that
I
would
really
like
for
the
spec
to
keep
descriptor
intact
as
describing
its
content.
So,
in
this
case,
I
would
say
like
I
would
I
would
consider
the
example
on
the
screen
here,
as
a
implementations
should
not
do
this,
because
the
scratch
data
is
not
Cyclone,
DX
plus
XML,
that
implementation
should
determine
a
media
type
for
their
config
blob,
that's
appropriate
for
them,
but
is
also
valid
use,
uses
valid
content.
H
I
would
say
not
I
would
say
that
the
the
sort
of
the
it
would
be
up
to
I
think
the
s-bomb
people
to
come
together
to
decide
on
what
they
want
as
their
whether
that's
Cyclone
DX
on
their
own
or
Cyclone,
DX
plus
spdx.
You
know
whatever
Consortium
exists,
they
are
free
to
decide
on
what
their
chosen
artifact
type
is,
but
if
Cyclone
DX
chose
to
go
their
own
way,
they
could
choose
application,
vnd.cyclone,
DX
artifact,
and
that
would
be
there.
H
It
would
not
be
I
think
the
the
client
that
would
put
determine
the
config
it
would
be
the
the
type
of
the
artifact,
the
artifact,
whatever
the
artifact
spec,
is,
and
we're
not
dictating
what
those
artifact
specs
are.
G
I
want
to
say,
I'm
happy,
but
I
think
yeah
I
have
a
terrible
idea.
G
That
might
be
good
what
if
we
registered
a
structured
suffix
with
Ayanna,
that's
like
Plus
oci,
and
if
and
we
can
Define
what
that
means
in
some
way
like
could
we
come
up
with
a
definition
of
the
plus
oci
suffix?
That
means
like
hey.
G
This
is
Jason,
and
often
it
is
an
empty
Json
object
and
it
means
that
look
elsewhere
in
this
wrapping
document
for
Content,
that
is
XYZ
media
type.
You
know
like
I,
that
seems
nuts
to
me,
but
also
maybe
solves
this
problem
in
a
way
that
we
don't
have
to
just
coordinate
between
100
people.
F
G
Yeah,
so
I
don't
know
that
I
get
the
use
case
of
like
I,
want
the
artifact
type
to
be
this
single
blobs
media
type,
but
that
presumably
that's
useful.
G
What
I'm
suggesting
Brandon
is
plus
XML
plus
SEI,
but
if,
if
our
problem
is
that
the
descriptor
is
wrong,
when
you
do
this,
you
know
this
is
not
something
I
would
do,
but
if
people
want
to
do
this
and
the
descriptor
is
wrong,
when
you
do
this,
then
we
could
make
it
correct
by
defining
this
oci
structured
suffix
and
you
know
defining
it
to
be
whatever
you
want,
such
that
the
things
people
want
to
do
are
no
longer
incorrect.
G
But
yeah
I
I
miss
Vincent's
suggestion
here,
but
yeah
I.
This
seems
fine
I
think
maybe
it's
gross
I.
Don't
know
people
hate
this.
F
You
know
it,
it
defines
that
this
thing
is
a
rapper
for
that
specific
layer
in
some
way,
if
you
add
the
media
type,
you
would
have
done
that
right,
but
the
media
type
is
already
reserved
for
the
Manifest
I
mean
I,
don't
see
a
problem
here
again.
This
is
something
that
sticks
in
the
Manifest.
No
client
is
going
to
see
it
like
the
search
and
filters
would
not
use.
This
is
what
you're
saying
right.
G
I,
don't
know
if
every
artifact
type
would
use
this
or
if
only
ones
that
aren't
Jason
would
want
to
use
this.
You
know
we're
kind
of
like
finding
the
seams
between
implementation
behavior,
so
maybe
it
just
makes
sense
for
everything
to
be
plus
oci.
So
it's
simpler
and
you
can
just
I
think
I
need
that
yeah.
H
I
think
we
can
probably
think
of
two
sort
of
categories
of
artifacts
here.
So
there's
like
the
helm,
Charter,
Singularity
or
maybe
more
complex
artifact
that
might
be
multiple
layers
might
be
as
complex
as
an
oci
image.
H
In
terms
of
you
know,
there's
some
sort
of
structure
to
those
layers,
and
maybe
they
have
they
have
their
own
config
format,
even
and
for
those
examples,
I
think
this
first
yeah
this
having
like
your
own
vnd.example.config
Json,
that
makes
sense
for
single
file
append
to
a
you
know:
we're
essentially
appending
a
single
file
or
blob
to
a
existing
image
or
artifact
by
refers
API,
I.
H
Think
having
some
sort
of
example
for
that
use
case
and
calling
out
yeah
I,
think
having
like
a
plus
oci
or
or
we
have
would
we
have
the
ability
to
register
with
Ayanna
a
prefix
so
that
we
could
say
vnd.oci
dot,
artifact.x,
you
know
or
something
to
embed
I
guess
the
existing
media
type.
Maybe
that
plus
oci
is
the
right
way
to
do
it,
but
I
think
it
is
yeah.
H
Okay,
then
yeah
I
think
this
makes
sense,
because,
if
I
use
the
refers
API
on
whatever
this
I
guess,
I
don't
see
a
subject
here,
but
whatever
this
refers
to
is
referring,
do
I'll,
see
application,
Cyclone,
DX,
plus
XML
in
the
response
so
refers
API,
so
I'll
be
able
to
know.
Oh,
this
is
something
I
can
handle
and
for
these
single
file.
Appends
I,
like
that
use
case,.
C
C
Could
be
so
you're
saying,
make
the
layer
self
empty
and
put
the
Cyclone
DX
up
here
the
day
itself
up
here.
D
B
D
G
C
C
So
are
people
with
a
strong
opinion
that
you
really
do
want
to
have
that
plus
oci
in
there
or
because
I
mean
for
my
cell
phone
is
coming
out.
The
other
end,
I'm,
just
searching
on
artifact
type
and
I,
know
that
I'm
looking
at
artifact
type,
which
means
this
is
an
artifact,
which
means
my
actual
content
of
the
artifact
is
going
to
be
in
the
layer
and
that's
where
I
can
find
it.
G
Think
that
the
the
nice
thing
of
this
potential
solution
is
that
we
have
a
really
straightforward
prescribed
way
to
wrap
a
single
file
or
a
single
layer
that
doesn't
require
everyone
to
come
up
with
their
own
unique,
arbitrary
string.
It's
just
oh
to
you.
If
this
is
one
document,
just
a
pen
plus
SEI
and
that's
your
media
type
instead
of
everybody
comes
up
with
their
own.
Like
often
incorrect
media
type
for
their
artifact.
C
H
D
F
H
Yeah
I,
like
the
plus
oci
approach
and
I
I,
think
that
should
be
a
prescriptive
example
in
the
pr
or
on
subsequent
PR.
G
I
think
it
would
be
interesting
to
try
to
register
I
think
I'm
too
mentally
ill
to
do
something
that
frustrating
and
boring
but
I'm,
happy
to
suggest
it
and
have
someone
else.
Do
a
leg,
work.
I
H
So
this
would
to
recap
this
would
allow
single
blob
authors,
who
know
what
the
media
type
of
The
Blob
is
that
they're
pushing
to
have
a
prescribed
config
media
type,
where
it's
just
a
trivial
change
to
the
media
type
they're
pushing
as
the
blob.
That
is
also
not
incorrect
for
the
config
descriptor
it
it.
The
plus
oci
will
indicate
that
it
has
to
be
a
valid
I
guess
in
this
case,
Json
object.
H
Suppose
you
could,
as
long
as
all
of
the
layers
are
the
same
media
type.
That
would
make
sense
to
me
as
well
application,
jpeg,
plus
oci
and
then
just
a
list
of
jpegs
in
the
layers.
I,
don't
know.
C
F
H
I,
don't
want
to
throw
too
large
of
a
wrench
in
this,
but
once
we
register
plus
oci,
that's
also
a
fairly
binding
thing
with
Diana.
So
would
we
want
something
other
than
plus
oci?
Would
we
want
like
plus
oci
artifact,
or
something
like
that,
just
to
not
tie
up
the
oci
term.
D
G
I
think
we
could
Define
it
in
such
a
way
that
we
can
update
it
where
the
definition
depends
on
the
context,
but
I
want
it
to
be
short.
F
G
That
could
be
invalid
or
we
could
Define
it
as
like.
The
first
layer.
H
Given
the
context
of
the
refers
API,
I
think
as
long
as
all
of
the
layers
match
that
format,
then
it
makes
sense
to
me
like
if
I'm
searching
I
could
search
via
refers
API
using
the
query
parameter
for
this
cycle.
Dx
plus
XML,
plus
oci
and
I
will
get
back
a
list
of
manifests
that
contain
ideally
only
layers
containing
that
blob
type.
G
That
seems
reasonable,
I
mean
I
think
as
long
as
the
manifest
contains
any
layers
with
the
wrapped
media
type.
This
is
useful
to
clients.
It
may
be
that
the
Manifest
contains
supplementary
layers
with
different
media
types,
but
those
are
not
the
primary
purpose
of
this
artifact,
so
I
I
would
be
fine
with
defining
it
such
that
the
layers
contains
at
least
one
descriptor
with
the
media
type
truncate
Plus
oci
off
the
end.
D
C
I
G
I
also
think
this
is
a
reasonable
solution,
so
I
I
agree
with
Michael.
C
Kinda
the
case
for
me
was
that
we
were
trying
to
document
guidance
for
people
that
wanted
to
do
this
in
oci.
We
weren't
saying
you
had
to
do
it
this
way.
We
were
trying
to
give
them
some
kind
of
guidance,
so
there
was
some
kind
of
semblance
of
conformity
between
different
people
producing
the
same
content.
C
So
if
you
have
a
trivia,
you
have
an
anchor.
You
have
all
these
other
tools
out
there
all
producing
whatever
their
scan
format
was
that
they
could
push
it
up
to
the
registry
and
all
the
clients
need
to
consume.
It
could
all
consume
the
same
thing
without
having
to
say
I
need
to
consume
the
trivia
version
of
this
or
I
need
to
consume.
C
J
G
That's
not
me,
that's
not
for
me,
I,
no
I,
that's
to
make
me
slightly
less
upset,
but
yeah
I
agree
with
Aaron
I
think
this
is
Aaron's
point
it's.
The
descriptor
is
wrong.
If
we
tell
people
to
do
this
and
the.
E
G
G
Useful
when
you
have
an
existing
media
type
that
like
isn't
valid
Jason
and
you
want
to
wrap
it
as
an
artifact
in
a
predictable
way,
this
kind
of
short
circuits
to
like
distributed
registry
of
infinity
arbitrary
strings
for
wrapping
one
file,
which
I
imagine
is
a
fairly
common
use
case.
Thank.
J
H
You're
fine
now
you'll
have
a
prescribed
way
to
upload
your
cat
gifs.
That's
what
we
really
wanted
to
do.
Yeah!
That's
what.
C
H
G
Yeah
I
I'll
point
out
that
I'm
very
happy
with
this,
because
this
implements
in
a
very
gross
and
roundabout
way,
my
suggestion
that
we
make
descriptor
something
you
can
push
to
a
registry
and
we've
kind
of
achieved
this,
but
not
quite
like
I,
would
love
it
if
you
could
just
put
a
descriptor
as.
D
G
D
C
C
I'm
seeing
some
nods
so
I'm,
assuming
that
I'll
keep
this
all
in
one
PR,
even
though
it's
got
a
couple,
little
small
cleanups
in
their
Edition,
all
right
Aaron
did
you
want
to
talk
about
10
30
or
is
that
something
separate.
H
No,
it's
a
this.
Is
the
clarifying
share
the
right
screen
here?
H
Yes,
this
is
clarifying
the
use
of
it
was
random
fashion
image
back
in
general,
for
use
of
artifacts
and
in
particular,
clarifying
A
lot
of
the
must
be
ignored
language,
so
I
would
love
a
review
on
this
to
make
sure
I'm
changing
the
ignored
to
must
not
generate
an
error
in
all
the
right
places
and
I
think
the
other
key
change
here
is
sort
of
opening
the
door
to
if,
in
the
future,
oci
wants
to
adopt
in
a
new,
manifest
type
that
there
were
some
questions
about.
You
know.
H
Will
registry
support
me
pushing
a
new,
manifest
type,
and
so
this
sort
of
clarifies
that
registry
implementations
which
just
are
involved
in
storing
and
copying
content,
should
accept
unknown
manifest
types.
They
might
have
no
semantics
right,
they're
not
going
to
parse
it
they're
not
going
to
implement,
subject
and
refers,
and
things
like
that
on
a
arbitrary
blob,
but
they
will
accept
it.
C
That's
the
case,
I
think
you'll
see
people
not
agreeing
on
just
because
Registries
parse,
the
Manifest
and
they're
parsing
for
the
blobs
and
that
manifest
they're
doing
garbage
collection
based
on
that,
and
so,
if
they
see
an
unknown
manifest
pretty
much
every
registry
out
their
day
rejects
it,
which
means
there
are
no
oci
compatible
registries.
G
H
Yeah
I
wanna
I
wanna
figure
out
a
way
to
get
out
of
the
Log
Jam
of
adding
new
manifest
types,
and
if
we
cannot
prescribe
that
as
of
some
oci
spec
that
new
manifest
like
unknown
manifest
types
must
be
accepted,
then
we're
always
going
to
end
up
in
this
sort
of
argument
about
backwards
and
forwards.
Compatibility
we'll
just
never
be
able
to
resolve
that,
because
no
new,
manifest
type
exists
in
oci,
1.0,
right
and
so
let's
say
1.0
Registries
will
reject
it.
H
Yeah
I
guess
the
question
there
is
that
doesn't
really
address
the
the
charter
and
the
backwards
compatibility
point
being
raised
right,
and
so
we
need
to
adopt
language
somewhere.
That
ensures
a
path
to
forward.
You
know
new
types,
because
otherwise
the
someone
can
always
in
the
future,
and
it
might
not
even
be
any
of
the
people
in
this
call.
H
C
G
The
current
extensibility
mechanisms
in
oci
1.0,
don't
allow
us
to
do
things
like
add
a
new
manifest
which
sucks
it
would
be
cool
to
have
a
breaking
change
that
unlocks
more
extensibility
mechanisms
in
some
way.
I.
Imagine
that's
like
a
2.0,
but
I
want
I
want
this.
You
know
it
shouldn't
break
everyone.
If
we
add
a
new
manifest
type,
there
needs
to
be
a
way
to
write
a
client
or
a
server
such
that.
B
You
can
John
I
mean
there
was
one
pull
request.
We
can
probably
revert
that
modify
it,
so
you
can't
have
an
additional
media
type.
You
could
only
have
one
image
media
type.
We
that
that
commit
probably
needs
to
be
reverted,
but
originally
we
allowed.
For
matter
of
fact,
it
was
a
requirement
to
allow
for
additional
media
types,
including
additional,
manifest
items.
G
B
I'm
just
saying,
as
far
as
backwards
compatibility
goes,
a
new
API
or
a
new
manifest
doesn't
break
the
old
Solutions
right,
the
old
apis,
the
old
applications.
They
don't
use
the
new
API
and
a
new
client.
That's
using
a
new
API,
well
he's
on
his
own
from
that
perspective,
because
that
would
have
been
a
2.0
API
or
a
1.3
or
whatever
it's
going
to
be
just
saying.
H
Yeah
I
think
I
think
as
part
of
this
PR,
so
I'm
not
prescribing
any
sort
of
fallback
method
or
even
just
describing
like
what
a
new
manifest
type
would
be,
although
if
I
were
to
think
in
the
hypothetical
of
I,
am
creating
a
Fubar
manifest
and
it
references,
maybe
some
blobs
and
manifests
in
that
spec,
and
you
want
to
do
garbage
collection
on
that.
I
think
the
fallback
for
that
sort
of
approach
would
be
they
would
have
to
add
image
or
image.
H
Index
manifests
right
and
push
them
to
you
know,
sort
of
like
we're
doing
with
refers
right.
They
would
have
to
have
a
fallback
that
essentially
registers
those
blobs
and
manifests
to
be
discoverable
via
garbage
collection
right
and
what
I
don't
want
to
necessarily
get
into
the
gritty
details
of
prescribing
something
that
we
don't
know
is
going
to
happen
yet.
But
I
do
want
to
enable
optionality
in
the
future
and
I
think
that's
what
I'm
trying
to
do
here.
H
I'm,
also
trying
to
make
sure
that
tools
like
4S,
CP
and
others
that,
like
copy
or
you
know,
proxies
that
proxy
content.
For
example,
I.
Think
it's
a
really
important
use
case
is:
if
I
have
a
registry
mirror
I
really
do
not
want
that
registry
mirror
to
be
holding
me
back
on.
H
G
Mirrors
things
if
I
can't
parse
the
Manifest
to
know
what
content
it
references
but
yeah
like
yours,
should
not
fall
over
because
the
layers
have
a
different
media
type
than
they
expected.
Certainly,.
G
H
I
think
it
would
be
helpful,
maybe
we're
at
the
end
of
the
call
for
review
comments
on
this
PR
before
the
next
call.
If
anyone
has
you
know
opinions
about
this,
especially
on
yeah
this,
this
line
here,
I
think,
is
potentially
contentious
and-
and
we
could
probably
consider
this
PR
with
or
without
it,
but
I
would
love
to
review
comments
on.
C
B
Some
comments,
yeah
yeah,
some
comments
on
that
I
mean
basically
the
problem.
Is
you
chunked
it
up
right,
and
what
are
you
going
to
do
with
the
remainder
at
the
end,
are
we
going
to
require
that
the
remainder
would
be
tacked
on
to
the
last
chunk
so
that
nope
it
still
meets
the
minimum
or
are
we
gonna
not
support
the
minimum
for
the
last
chunk
either.
B
For
the
last
one
well,
why?
Except
for
that's
the
part
that
I'm
not
I'm,
not
following,
if,
if
there
was
a
problem
in
storage
and
not
supporting
any
chunk
of
less
than
that
side,
which
I
think
was
the
original
problem,
then
we
haven't
really
solved
it
or
are
they
going
to
in
the
registry
tack
on
the
last
chunk,
it's.
C
C
B
J
C
C
Everything
in
there
was
intentionally
a
should
so
that
I
didn't
force
anything
because
I
figured
some
clients
are
going
to
try
to
do
it
and
it's
just
like.
Well,
if
you
ignore
the
header,
then
you
ignore
the
header
and
you're
going
to
get
an
error
message
back
from
the
server.
That's
just
what's
going
to
happen
to
you,
but
for
the
other
ones
that
I
just
I
left
it
as
a
show.
Just
so
the
clients
would
know
that
hey.