►
From YouTube: OCI Weekly Discussion - 2023-03-23
A
B
B
D
Just
haven't
been
here
for
a
bit,
so
I
figured
I'd
drop
in
and
I
also
owe
you
a
a
document
for
the
meeting
at
kubecon.
So
I
will
take
care
of
that
while
we're
all
here
hooray
boom.
B
Sounds
good,
do
we
have
things
that
are?
Did
he
already,
so
she
might
pull
that
outside
or
a
document
that
we
merged
that
one?
Oh
it's
just
down
below
on
the
Kube
condo.
We
have
people
here
that
are
going
to
be
attending.
D
Yeah
look
in
the
calendars
and
it
is
over
on
the
oci
calendar.
It's
the
19th
and
it's
going
to
be
stupid
early
for
the
people
in
the
US.
But
it's
gonna
be
normal
time
for
like
people
up
in
Amsterdam.
So.
B
B
No
worries
it
gave
us
a
minute
to
make
sure
everybody
had
a
chance
to
show
up
here.
I
still
see
people
blinking
in
out
here
so
I
think
that's
about
Quorum,
so
we
can
go
ahead
and
get
this
thing
started.
I
do
see,
though,
warning
that
distribution
spec
was
merged.
I
was
gonna
hit
that
one
up
later
on.
We
can
talk
that
or
we
can
talk
the
1029
either
way,
whichever
one
people
think
is
more
of
a
priority.
I.
C
B
C
C
Magic
he
just
he
just
knows
what
he's
doing
it's
crazy,
yeah
I'm
happy
to
shut
up
and
talk
about
actual
things.
I
just
wanted
to
announce
that
merged
no.
B
That
that
one
was
really
awesome,
I'm
pushing
Docker
right
now,
because
clearly,
Docker
is
doing
stuff
discussing
people's
attention
lately
and
so
I'm
pushing
him
to
see
if
they
want
to
adopt
this
on
their
side
and
try
to
get
that
out
earlier
for
anything
that
happens
registry
layout.
That
might
be
a
good
way
to
give
in
user
feedback
if
they
start
pulling
stuff
from
repos
that
aren't
being
updated
or
something.
C
Yeah,
if
there's
anyone
over
there,
including
on
this
call
that
has
anybody
any
contacts
on
the
docker
CLI
side.
That
would
be
interested
in
implementing
the
client
side
of
this
I'm
super
interested
in
that
and
would
would
love
to
help.
B
Sebastian,
here's
clearly
not
here
he
did
say
that
he
was
interested
in
getting
some
work
on
that
one
over
there.
So
I
think
that's
going
to
happen.
I
just
don't
know
time
frame,
but
yes,
they,
like
it
I,
think
their
big
concern
was
on
the
Hub
side,
the
place
they
were
going,
the
source
of
data
they
need
to
inject.
C
Yeah
I
think
yeah
cool
awesome,
I'm
excited
for
this
to
start
filtering
out
to
Registries
and
clients.
This
will
be
super
cool,
super
cool.
E
Think
I
might
have
missed
what
the
start
of
the
conversation
was.
Is
this
is
this
about
the
the
header
on
pushing
blobs.
B
B
Cool
well
I
think
we
have
Chit
Chat
enough
to
give
everybody
a
chance
to
show
up.
A
theory
might
want
to
talk
about
10
29
first,
because
that's
the
one
that
seems
to
have
the
most
back
and
forth
amongst
the
community,
which
is
a
the
first
question.
I
was
going
to
throw
in
there,
which
maybe
should
be.
B
E
E
I,
don't
know
if
we
can
I
I,
don't
know
I
think
we
were
all
in
this
call
at
least
like
comfortable
with
plus
oci,
so
I
don't
know
if
we
can
really
proceed
as
a
discussion
without
Vincent
here.
Unless
someone
wants
to
take
that
I
I,
don't
know
if
someone
could
properly
sort
of
advocate
for
the
position
without
him.
B
Well,
I'll
say
that
I
wasn't
thrilled
it's
it's
not
that
I,
it's
not
that
I
was
uncomfortable
with
it.
I
just
wasn't.
Thrilled
and
I
can
understand
the
concern
about
the
plus
RCI
and,
as
just
yeah,
another
thing
to
keep
track
of,
and
it's
slightly
mutating
the
data
a
little
bit
in
a
weird
way.
So
there
were,
there
was
reasons
to
ask
questions
about
it.
B
E
Sort
of
a
temperature
check
should
we
just
like
thumbs
up
thumbs
down
like
if
there
was
an
artifact
type
field
on
the
root
level
of
the
Manifest
I.
Think
that
would
make
the
most
sense
to
me.
Is
there
anyone
who
would
be
opposed
to
that
here.
E
Option
four
fall
back
to
be
clear,
like
it
would
be
in
the
refers
API.
It
would
check
that
first
and
then
the
config
media
type.
B
B
G
E
And
that's
because
in
the
refers
API,
the
index
response,
the
artifact
type
is
the
artifact
type
of
the
Manifest
right
right.
And
in
this
case,
if
we
put
it
in
the
config
descriptor
it.
Wouldn't
it's
not
really
describing
the
artifact
type
of
the
descriptor
right.
The
Crispers
Target
right.
G
And
when
we
added
the
embedded
top
level
media
type
field
to
all
the
manifests
that
also
kind
of
set
a
precedent
for
maybe
adding
an
artifact
type
field
to
manifests.
G
Yeah
I
I
would
I
would
lean
towards
four.
As
being
like
the
simplest
thing.
That's
easy
for
us
to
do
that
doesn't
involve
us
different
standards.
Body
option
two
is
like
cute,
but
I
only
like
it,
because
I
came
up
with
it
and
I
told
him
that
we
really
want
to
do
that.
E
I
I
think
I
like
option
four
from
a
client
implementation
perspective
as
well.
Is
that
if
we
put
a
you
know
the
guidance
for
artifacts
section,
artifact
should
populate
the
artifact
type
field
right,
it's
a
little
bit
simpler
for
clients
run
times
and
non-run
time.
Clients
to
distinguish
am
I
looking
at
something
that's
purporting
to
be
more
of
a
an
image
or
more
of
an
artifact.
E
By
checking
the
existence
of
that
field,
it's
not
going
to
be
perfect.
Of
course
we
have
some
some
Legacy
artifacts
and
Registries
today,
but
I
think
that's
simpler
to
me.
G
Yeah
the
only
place
that
gets
a
little
more
complicated
is
registry
implementation,
but
we're
already
asking
them
to
change
like
they
have
to
write
new
code
to
do
this,
so
I
think
it
is
fine
to
have
an
additional
string
check
if
artifact
type
is
not
set.
Then
look
at
config
type.
That's
pretty
straightforward
to
me.
B
H
B
And
I
know
when
he
and
I
were
chatting.
His
big
concern
was
that
it
took
so
much
negotiating
an
effort
getting
everybody
Upstream
to
coordinate
on
this,
and
now
we're
going
back
back
to
the
well
and
saying
okay,
we
need
you
to
change
everything
again
wow,
it's
not
a
huge
change,
but
it's
still
going
back
and
asking
for
a
change.
H
B
Sure
we're
all
we're
all
giving
something
up
here.
I'm
gonna
put
an
example
in
the
notes.
Just
so
we
have
something
to
work
from
just
because
I'm
doing
code
formatting
it's
easier
on
this.
E
E
That's
right,
but
current
sample
size
is
one
vote.
E
E
G
I
Hi
hi,
so
I
guess
like
to
follow
up
on
toddy's
kind
of
funny
remark,
but
also
true,
like
we
did
give
up
what
I'm
curious
about
in
the
last
couple
of
weeks.
What
why
do
we
need
exchange
like
that
like
if,
if
we're
talking
about
actually
putting
a
new
field
in
the
image
manifest
like
wooden
clients,
then
potentially
start
using
that
and
like
don't.
I
We
have
like
this
kind
of
some
of
the
same
problems
that
everybody
had
with
a
new
media
type
to
begin
with,
okay
and
I've
been
checked
out
for
a
couple
of
weeks,
so
I
apologize
but
like
I
thought
we'd
sort
of
land
on
okay,
let's
codified,
what's
an
open
containers,
artifacts
and
call
it
a
day.
This
doesn't
feel
like
that.
B
I
H
H
For
me,
we
are
breaking
a
lot
of
things
and
a
lot.
A
lot
of
people
are
unhappy
right.
I
can
tell
you
my
my
whole
team
is
unhappy
with
this
back
and
forth
and
add
this
field
remove
this
field.
It's
just
not
productive
at
all,
and
everything
was
ready
and
all
the
Registries
that
actually
went
on
the
path
with
the
artifact
manifest
they
were
like
ready
to
release
it
and
now
anyways.
Sorry,
I
don't
want
to
actually
derail
the
conversation.
B
H
B
And
if
you
get
your
mic
work
and
feel
free
to
interrupt
me
at
any
time
or
for
right
now
sorry,
my
problems
are
the
story
of
Our
Lives,
so
I
think
what
we're
saying
is
add.
A
new
artifact
type
up
top
I
do
have
an
open
question
here.
What
do
we
want
this
to
be
set
to,
and
then
the
rest
of
this
is
just
what
we
already
have
before
annotation
subject
layers.
B
E
So
I
think
were
we
to
standardize
an
artifact
type
field.
I.
Think
the
the
question
marks.
There
could
be
a
oci
standardized
scratch
media
type
right
like
we
could
do,
vnd.oci
dot,
stretch,
Json
or
something.
E
I
I
think
I,
don't
know
if
anyone
here
on
the
call
actually
has
any
preference,
so
I
think
if
you
just
wrote
something
down
and
some
put
that
in
the
pr
I
think
everyone
here
would
be:
okay
with
that
Alyssa.
G
G
If
we
want
to
optimize
for
say
broadest
compatibility
with
existing
software,
it
might
make
sense
to
just
use
the
normal
config
media
type
for
this,
so
that
if
a
registry
behaves
properly
By
ignoring
unknown
Fields,
but
behaves
improperly
by
only
accepting
certain
config
media
types,
then
we
can
still
leverage
that
registry
or
software
or
whatever
but
like.
If
we
only
care
about
things
that
are
technically
correct
and
not
practically
useful
I
would
say
like
this
could
just
be
application.
Slash
Jason,.
B
I
With
that,
would
that
mean
that
then
1.1
would
promote
refusing
other
config
media
types
like?
Would
we
because
I
know
like
open
container
slash,
artifacts
was
never
part
of
1.0,
but
it's
because,
like
I,
think
that
was
kind
of
the
root
of
the
argument
was
like
everybody
does
this
we
might
as
well.
Just
do
it
so
now
we're
saying
like
everybody
does
this
and
they
better
stop
or
would
it
be
like
either
or.
B
G
There
may
be
room
for
like
a
should
that
describes
what
everyone
is
doing
already
basically
and
a
must
that
describes
hey
if
you
refuse
to
like
play
along
with
the
scheme,
then
we're
gonna
we're
adding
this
must
so
that
you're
technically
not
in
compliance
with
1.1,
because
you
don't
support
this
scratch
string
that
we
made
up.
That
means
nothing.
G
But
there's
also
yeah,
you
know
people
who
aren't
playing
along
registry
side
or
too
too
conservative
with
their
Json
strings.
I,
don't
know
if
it's
worth
having
some.
You
know
dancing
around
that.
I
Right
so
I
mean
I.
Think
I
think
this
goes
directly
to
the
point
that
I
was
trying
to
make
all
along,
which
is
the
backward
compatibility
guarantee
in
a
storage
specification,
means
that
artifacts
have
a
life
in
the
future,
not
that
new
artifacts
can
be
pushed
to
Old
storage
mechanisms.
I
That
seems
to
be
what
we
over
rotated
on
is
making
sure
that
a
1.1
client
won't
break
when
it
tries
to
push
to
a
1.0
registry.
I
lost
the
argument
and
trying
to
say
that's
not
an
actual
problem.
This
would
be
right,
taking
1.0
artifacts
that
set
config
media
type
and
migrating
them
to
a
1.1
registry,
and
they
break
because
we
don't
allow
config
media
type
to
be
anything
else.
I
I
I
A
minimum
yeah
because
yeah
in
the
absence
of
a
spec
people,
adopted
that
as
an
ad
hoc
spec
right,
especially
since
it
was
in
the
same
repos,
very
confusing,
which
we
all
agree
with
I,
just
really
I
mean
I
I
feel
like
that
is
well.
I
We
doing
here,
but
that's
okay,
so
I
I,
would
say:
yeah
I
think
that's
a
that's
at
a
minimum.
We
need
to
have
some
should
language
in
there.
B
J
Okay,
the
last
thing
we
were
talking
about
in
the
busy
slack
channels
probably
still
holds
for
me
if,
if
yeah
I've
already
gone
over
that
before
I
joined.
B
B
That
was
the
one
that
I
wasn't
thrilled
about
asked
you
about,
and
you
said,
no
so,
okay
throughout
the
option,
artifact
type
could
just
be
done
on
the
config
descriptor
that
got
nicked
today,
just
people
saying
that
doesn't
really
fit
in
the
config
descriptor.
It's
really
defined
what
the
image
manifest
is
not
what
the
fake
descriptor
is,
and
so
we're
going
down
to
saying.
Let's
put
it
on
the
image
manifest,
which
turns
it
into
a
manifest,
looks
like
this.
B
Where
we
have
artifact
type,
the
configure
type
is
probably
going
to
be
some
static
string
for
this
scenario.
It
doesn't
mean
that
other
people
pushing
their
own
artifacts,
wouldn't
have
their
own
string
in
there,
where
Helm
charts
have
a
config
cosine
would
have
their
config
four
same
potentially,
but
if
they
don't
have
anything
for
the
config
and
they're
just
saying,
instead
of
scratch,
value
they've
got
the
option
to
find
the
artifact
type.
J
I
think
so
because
it
to
me,
okay,
so
just
real
briefly
like
even
even
on
like
when
we
were
iterating
on
that
over
over
the
last
month
or
two
having
some
kind
of
a
predefined
media
type.
Whatever
it's
called,
and
here
you've
got
like
scratch,
oci,
whatever
you
know,
OCS
scratch,
that's
fun,
I
think
defining
that
is
is
probably
the
important
part.
The
plus
and
Json
at
the
end
is
just
because
it
is
technically
a
Json
document
and
plus
oci
just
didn't
make
any
sense
there
not
saying
no
to
it.
J
It
just
seems
like
a
misuse
of
it
and
so
having
these
fields
teased
out
a
little
bit
further.
I
guess
fine!
So
then
you
hit
the
media
type.
So
in
this
situation,
the
media
type
and
architect
that
artifact
type
sitting
next
to
each
other
media
type
is
describing
is
a
self-describing.
B
G
J
G
Where,
where
media
type
is
like,
Json
parser,
useful
and
artifact
type
is
semantics
useful.
J
C
B
The
key
for
me
is
that
this
artifact
type
gets
pulled
up
into
three
First
Response,
and
so,
if
I
have
four
different
s-bombs,
two
cyclodex
to
spdx
one
XML,
one
Json,
however,
they
sort
it
out.
I
want
to
make
sure
that
from
the
top
of
the
black
and
sort
out,
I
could
always
put
it
down
as
an
annotation.
If
that
was
maybe.
J
Yeah
so
I
guess
two
two
things
I
like
that:
it's
not
in
the
to
script
or
in
making
that
whole.
You
know
what
is
the
function
of
the
media
type
field
and
a
descriptor
now
overloaded,
because.
F
J
Was
seeming
like
a
problematic
thing,
but
what
if,
in
this
scenario,
you
had
more
than
one
descriptor
in
the
layers
area?
Is
it
a
one-to-one
mapping
of
that
Art
Attack
fact
value
to
what's
in
the
layers
doesn't
have
to.
B
E
I
think
it's
not
the
the
answer
there
is
we're
not
being
prescriptive
right
is
that
it's
up
to
the
implementation
to
decide
if
they
would
observe
their
own
media
type
strength,
they
can
do
whatever
they
want
in
the
layers.
J
G
I
think
my
experience
with
this
is
we
needed
several
examples
in
the
spec
of
common
use
cases
to
make
a
very
clear
like
how
to
actually
implement
this,
because
I've
seen
a
lot
of
people
just
they
look
at
the
examples
they
say.
Okay,
all
data
will
always
look
like
this
and
then
code
against
that.
B
Yeah
I'm
definitely
pushing
to
get
examples
in
there
just
because,
for
example,
cosine
starts
saying:
here's
how
we're
going
to
push
up
best
bombs
and
the
question
quickly
came
to
their
side
of
okay.
If,
if
we
got
a
way
to
push
s-bombs
over,
there
is,
is
this
the
proper
media
types
for
everybody
to
do
s
bombs
and
it's
a
cosine,
specific
config
need
type.
So
I
think
I'll
be
much
happier
if
we
get
something
that
everybody
pushing
the
Cyclone
DX
everybody
pushing
the
spdx
uses
something
that's
going
to
be
consistent
across
all
the
tools.
E
Yeah
and
I
think
you
know
it's
up
to
those
sort
of
parties
to
agree
if
they
want
to
have
a
common
artifact
type
and
they
can
reach
that
consensus.
It's
not
oci's
place
to
mediate.
That.
F
I
had
a
question
on
so
John
made
a
comment
about:
why?
Don't
we
just
have
it
be
application
Json
for
the
config
media
type.
I
would
think
that
we
would
want.
Should
language
at
some
point
that
just
says
the
size
can
be
zero
and
just
leave.
The
object
is
empty,
but
I
feel
like
I
miss
some
conversation
that
led
us
to
this
like
custom
null
media
type
here
like
how
is
that
for
backwards,
compatibility.
B
I
B
I
Still
don't
understand
why,
though,
like
like
that
implies
that
Not
only
would
it
be
enforced,
but
it
would
also
be
automated
without
any
control
from
the
from
the
user
from
from
the
calling
context
I
just
like
I,
don't
understand
this
thread
of
logic
that
drives
us
to
these
back
bendy
kind
of
places.
B
I
I
This
is
a
simplifying
question.
This
is
not
a
starting
question.
I
really
want
to
know,
because
we
are
going
to
spend
weeks
and
you
will
keep
finding
things
like
this.
This
goes
back
to
my
original
point
of
like
look,
and
this
is
my
fault.
I
worked
on
storage
decks
for
the
first
decade
of
my
of
my
career,
like
we
never
thought
a
forward
compliant
client
would
be
able
to
talk
to
it
in
the
past
down
rev
Legacy
Storage
solution.
I
B
I
I
I
don't
mean
that
I
don't
mean
that
to
be
an
argument,
I'm
trying
to
clarify
so
okay.
So
what
you
were
talking
about
is
like
fallback
right
and
fallback
can
be
automated
or
it
could
be
manual,
but
either
way
what
you're
doing
is
you're
saying
this
client
doesn't
have
what
it
means.
It
will
fall
back
to
1.0
capabilities.
I
If
I
don't
have
that
and
I
just
create
a
1.1
thing.
Do
we
expect
that
to
work
in
a
1.0
registry?
The
answer
should
be
no,
but
it
seems
to
be
what
we're
trying
to,
and
here
what
we're
saying
is
Well
a
client
can't
push
something
that
a
1.0
registry
can't
handle,
which
I
just
I,
don't
think
should
matter
I
think
we
should
Define
this,
the
spec
that
we
need
at
1.1
and
then
Registries
will
follow
it
and
those
are
two
kind
of
different
things.
I
K
I
just
want
to
make
sure
I
understand,
like
the
the
implications
of
that
versus
the
like
the
reality
of
end
users.
Today
of
both
Registries
and
clients,
would
would
we
be
required,
then,
to
ask
them
to
pass
a
parameter
to
your
Docker
build
or
your
code
build
or
your
your
aorus
push
that
actually
says
what
version
of
an
oci
spec
you
want
to
use
to
create
that
and
because
I
don't
think
anybody
knows
most
users
of
these
clients
today.
Don't
have
that
level
of
understanding
of
what's
going
on.
I
I
We
need
to
guide
people
toward
the
right
way
to
adopt
new
features,
so
a
minute's
version
for
a
reason.
If
we
didn't
version
it,
then
it's
just
like
wild
west
and
what
works
works
and
what
breaks
breaks
and
that
frankly,
seems
to
be
what
we
have
in
1.0
right
now,
but
we'll
put
a
pin
in
that.
I
We
could
all
laugh
about
it,
at
least,
but
like
I,
think,
that's
a
really
good
hello
John
like
like
how
would
clients
do
that?
What
if
so
like
right
now
we
see
oras
notation
cosine
are
all
aware
as
just
three
candidates:
they're,
not
favorites,
I'm.
Sorry,
if
I
left
hers
out
but
like
they're
all
aware
of
this,
and
now
they
have
like
these
switches
to
be
like.
I
Oh
we'll
use
a
1.0
style
image
or
a
1.0
style
artifact
or
now
we'll
use
1.1
style
like
they're
they're,
starting
to
build
some
of
that
in.
But
it's
a
little,
you
know
it's
a
little
ad
hoc
because
the
spec
isn't
out,
but
that's
all
evidence
of
a
client
being
aware
and
asking
its
user.
What
do
you
want
to
do
right?
Are
you
targeting
a
1.0
registry?
You
better
use,
Legacy,
stuff,
otherwise
it'll
break
right
versus
versus.
You
know
the
idea
that
we
have
to
limit
the
spec
to
nothing
that
would
ever
break
and
I.
G
I
think
I
think
largely
how
we
got
to
this
point
is
my
fault,
so
I
feel
obligated
to
say
something,
but
I
think
why
we
are
at
the
point
of
like
okay,
let's
not
break
anything
ever,
let's
be
1.0
compatible
with
this.
Is
that
what
we
can
and
I
think
it
is
better
to
do
that,
because
we
can
bending
over
backwards,
doesn't
feel
good
and
I.
G
Don't
like
a
lot
of
this,
but
in
terms
of
like,
can
we
get
this
working
with
everything
that
exists
today
in
a
way,
that's
like,
let's
say
99.9
of
Registries
will
support
it.
That
seems
like
a
laudable
goal
to
have
so
that
we
can
like
move
on
with.
G
I
I
am
supportive
of
making
some
1.1
or
2.0
breaking
changes
to
introduce
something
like
an
artifact
manifest.
If,
with
that,
we
get
a
better
mechanism
for
upgrade
and
better
mechanism
for
adopting
new
features.
It's
just
that
you
know
the
same,
but
slightly
different,
such
that
it
doesn't
work
with
the
existing
clients
and
Registries
is
a
non-starter
for
me
and
so
I
think,
because
of
that
right,
because
we
pointed
on
that
to
the
Future
now
we're
at
the
point.
We're
like
okay.
G
Well,
let's
ship
something
and
we
might
as
well
make
it
work
with
everything
because
it
can
which
is
gross
but
I.
Think
pragmatic,
because-
and
you
said
at
some
point
like
you
know,
we'll
Define
this
as
1.1
in
Registries,
we'll
adopt
1.1
and
I
think
most
will.
But
I.
Don't
think
enough.
Will
for
me
not
to
be
annoyed
by,
like
random
support
requests
from
users
who
use
some
outdated
version
of
a
registry
that
they
don't
have
support
for
and
then
I
get
sad.
B
The
other
thing
I
wanted
to
piggyback
on
that.
The
the
big
part
for
me
is
if,
if
we
can
support
existing
registries,
why
why
we
have
two
choices
to
pick
from
while
we
pick
the
one
that
we
know
is
going
is
going
to
have
problems
on
some
Registries,
why?
Why?
Wouldn't
we
pick
the
one
that
works
everywhere?
B
That's
the
first
part,
but
the
second
part
is
from
the
end
user.
I,
don't
think,
there's
a
way
end
users
know
where
their
content
is
going
to
be
sent
to
after
they
push
it
to
the
registry,
and
so
you
push
it
up
to
one
registry.
It
can
get
copied
to
a
dozen
other
places.
So
if
you
get
all
the
apis
in
there,
you
do
all
the
checks
and
say
I
know
my
registry
has
1.1.
B
I
Right,
I
kind
of
going
backwards,
I
agree
with
you,
Brandon
I
there's.
This
happens
in
Block
copies
right
now,
right.
You
have
a
lot
of
file
systems
that
are
nvme,
aware
and
others
that
are
used
to
spending
rest
and
they
are
laid
out
totally
different
and
you
move
your
blog
copy
somewhere
and
stuff
can
go
sideways.
Real,
easy,
I
think
that
that
is
down
to
just
kind
of
part
of
being
used.
You
know
using
a
complex
system,
so
don't
disagree
with
you.
I
I
just
don't
prioritize
it
and
I
would
say
to
John-
and
this
is
a
this
is
a
me
for
posterity's
sake
and
then
I'm,
going
back
to
the
giving
up
posture
that
I
started
at
for
posterity's
sake.
Completely
agree
with
everything
you
said
as
well:
I,
just
don't
characterize
artifact
media
type
in
1.1
as
a
breaking
change.
I
I
think
that
is
a
big
difference
between
how
we
see
this
because
I
don't
think
new
features
and
a
forward
moving
specification
can
be
considered
breaking
if
they're
not
supported
in
a
implementation
of
a
Down
rep
version,
and
that's
really
what
we're
saying
is
like
I
got
the
new
shiny,
but
it
won't
work
in
the
old
dingy.
So
it's
breaking
change.
I
What
would
be
a
breaking
change
to
me
is
what
we
were
talking
about,
where,
if
we
forced
artifacts
using
image
media
image,
media
type
to
have
a
config
media
type,
that
is
a
specific
string
only
that
would
be
a
breaking
change
in
that
1.0
Style
ad
hoc
artifacts
could
not
move
to
a
1.1
registry.
They
would
they
would
you
know,
so
we
would
orphan.
We
would
abandon
data
that,
to
me
would
be
a
breaking
change.
I
G
I
E
Yeah
I
think
the
the
way
that
I
look
at
it
as
a
prospective
client
that
not
in
the
hypothetical
we
want
to
use
where
I
work,
oci
1.1,
whatever
shape
that
takes
what
I
care
about
is
what
Jesse
is
talking
about
is
I.
E
We,
if
we
look
at
issue,
1025
right
that
doesn't
truly
capture
all
of
the
possible
permutations
of
putting
artifacts
to
different
Registries
right
it
tests
sort
of
like
we
tested
a
tiny
subset
of
the
possible
values
in
all
of
these
fields
and
there's
no
guarantee
that
any
of
these
Registries
will
accept
my
company
dot,
boo,
dot
bar
plus
Json
right
as
a
config,
and
what
matters
to
me
is
an
implementation
is
specifying
that
oci
1.1
will
essentially
require
that
degree
of
compatibility
of
conformance
so
whether
that
takes
place
in
image
manifest
or
artifact.
E
You
know-
that's
I
have
relented
on
that.
But
I
think
that
is
my
point
in
in
PR
1030,
which
is
really
is
later
in
the
docket
I.
Don't
think
we'll
get
to
it
today,
but
I
think
that
is
what
matters
to
me
is
we
can't
I
cannot
rely
on
an
oci
1.0
registry
to
support
the
products
that
I'm
building
and
that's
because
there's
just
no
way
to
exhaustively
test
all
of
the
Registries
that
exist
today
with
all
the
possible
permutations
right.
E
But
if
oci
1.1
specifies
that
arbitrary
media
types
have
to
be
accepted,
then
I
can
say
to
my
customers
that
if
your
registry
supports
NCI
1.1,
then
our
product
supports
your
registry
right
and
that's-
that's
I,
think
the
value
of
specifying
that
and
it
you
know,
I-
think
we're
doing
a
lot
of
compromises
to
support
existing
registry.
So
the
lift
is
smaller.
That's
fine,
but
I
do
want
to
make
sure
that
we
support
that
Baseline
that
I
can
build
a
product
on
that's
what
matters
to
me
and
and
I.
E
B
H
Yeah
I
wanna.
Second,
actually,
what
Jesse
said
so
I
I
never
saw
one
point
or
artifact
manifest
as
breaking
change
right
and
we
worked
on
the
clients
and
we
actually
find
found
a
way
to
really
support
both
Registries,
the
old
one
and
the
new
one.
The
only
thing
that
actually
Brendan
I
remember
you
had
is
like
copying
between
old
and
new
one
and
automatic
copying.
H
That
is
the
kind
of
the
only
broken
scenario,
and
we
are
doing
all
this
kind
of
work
to
really
make
that
easy,
but
that
doesn't
mean
that
the
clients
cannot
do
it
right
and
we
had
implementation
where
the
client
was
able
to
copy
between
a
new
and
old
and
back
and
forth.
Of
course,
you
remember
we
we
wanted
to
have
also
this
addition
of
okay.
What
do
you
support?
H
So
we
can
make
that
easy,
but
it
was
possible
and
for
me
once
again
so
artifact
manifest
was
additive
change
and
it
was
if
you
are
1.1,
you
support,
support,
artifact
manifest
and
your
client
knows
what
it
is
it
talking
to.
So
we
even
implemented
the
client
to
do
automatic
kind
of
fallback
to
the
to
the
registry.
H
It
was
a
bunch
of
work
that
we
spent
actually
to
do
it,
and
there
were
a
couple
of
Registries
that
were
not
supporting
it
just
because
they
were
sending
error
messages
that
were
like
very
random
I.
Don't
know
whether
you
remember
that
discussion
that
we
had
at
the
time-
and
it's
like
once
again,
those
Registries
they
do
not
comply
with
oci
right
and
we
may
not
never
actually
get
them
to
comply
with
oci
because
and
again
so
I
just
wanted
to
put
it
on
the
record.
H
G
H
I
I'm
explaining
why
it
was
not
possible
not
because
actually
we
did
something
wrong
and
the
artifact
manifest
was
wrong.
It
was
not
possible,
for
other
reasons,
not
for
the
reasons
that
we
are
discussing
here,
and
that
is
my
opinion
on
on
the
problem.
Okay,.
G
I
just
want
it
possible
for,
like
the
shape
of
the
data
problems,
not
even
registering
implementations,
like
it's
logically
impossible
to
do,
because
people
want
to
sign
bytes
and
if
you
do
a
conversion
of
the
signed
thing.
Those
bytes
change,
and
so
you
can't
portably
move
signed
objects
around
without
breaking
the
signature.
H
That
is
true,
yeah
I
agree
with
that
the
the
signatures
will
be
broken
if
they
are
moved
because.
A
I
Raised
hand
brand
John,
that's
like
the
third
time.
You've
apologized,
you
really
don't
I
mean
I'm.
Speaking
for
myself,
you
really
don't
need
to
do
that.
Like
that's,
that's
we're
all
doing
this
and
we're
gonna
follow
a
majority.
Quorum
kind
of
vibe
and
and
Toddy
and
I
aren't
even
mad
we're
just
we
gave
up
that's
what
we
said.
So
you
know
it's
gonna
we're
gonna
get
spicy,
though.
If
you
keep
apologizing,
stop
apologizing.
B
If
I
Define.
That,
as
our
example,
are
people
comfortable
with
that
or
are
people
going
to
push
back
and
say?
No,
we
still
need
to
look
back
around.
Do
these
other
questions,
I'm
trying
to
get
a
temperature
check
from
the
room
of
whether
or
not
I
should
go
through
the
effort
of
implementing
this
or
not.
B
The
change
the
spec
is
an
image
spec,
but
the
usage
of
it
distribution
is
going
to
need
to
be
updated
to
tell
it
how
we're
parsing
the
media
type
to
pull
it
up
to
an
artifact
height,
so
artifact
type
was
originally
just
the
config
media
Titan.
Now
it's
going
to
be
a
conditional
it.
It
is
the
config
me
type
unless
you
have
an
artifact
type
and
then
you
use
artifact
type
if
it
exists.
I
Okay,
okay,
that
makes
sense
so
I
think
I
think
we'd
have
to
see
them
both
and
then
we
can
bring
it
together.
B
Yeah,
so
that
goes
to
my
other
comment,
which
was
I,
should
just
break
this
PR
up,
I'll,
probably
I'm,
going
to
close
10
29.
B
I'm,
going
to
reopen
a
new
one
with
just
my
nits
I
had
a
few
small
things
there
that
just
weren't
related
to
any
of
this
stuff,
so
I'll
get
that
updated
and
then
I'll
open
a
new
PR
with
everything
we've
been
talking
about
with
the
basically
the
guidance
and
the
new
artifact
type
field
and
everything
in
there
together
and
then
I,
don't
know
who
had
their
hand
up
next
toddy
or
at
the
top
of
my
page,
though,.
H
I
actually
have
a
very
small
question
before
the
end.
Maybe
John
has
more
but
I.
My
question
is:
do
we
have
in
any
ETA
for
when
the
spec
will
be
released
right
or
I'm
pretty
sure
that
a
lot
of
people
are
interested
about
that
and
I
know
that
there
are
long
discussions,
but
can
we
put
some
time
bomb
on
this
and.
B
B
They're
open
source
way
we
go
home
already:
John
Jump,
On
In,
so.
K
Yeah
a
question
for
you
on
the
the
last
part
there
of
pulling
the
artifact
type
up
to
the
refers
API.
Would
that
would
you
would
you
have
to
use
both
the
artifact
type
and
the
media
type
of
the
layers
in
order
like
if
you
wanted
to
filter
your
query
based
on,
like
I,
only
want
to
see
Cyclone
DX
XML
artifacts,
not
all
of
the
Cyclone
DX
objects.
B
That's
where
we
need
to
clarify
in
our
examples
of
what
to
Define
there,
the
stuff
I'm
going
to
put
in
distribution
is
just
saying
when
you
run
the
refers
API
call
or
when
you're
building
the
fallback
tag.
That's
represented
refers
API
response
that
you
first
pull
the
artifact,
I
really
exist,
and
otherwise,
if
that
doesn't
exist,
you
use
the
config
meta
type
and
that
goes
into
the
artifact
type
within
the
descriptor.
Within
the
refers
API
response.
B
We've
only
got
one
field
to
pull
up
if
you've
got
more
complicated
use
cases
there,
which
a
lot
of
us
do
I'm
there
with
you,
that's
where
we
have
the
annotations
getting
pulled
up,
and
so,
if
you
had
a
fingerprint
for
your
signing
key-
and
you
want
to
include
that
up
here-
you
can
do
that.
If
you
had
a
time
stamp
for
when
the
last
vulnerability
scan
ran,
you
can
put
the
timestamp
in
there
and
then
someone
could
query
for
the
last
vulnerability
scan
to
run.
We
deferred
all
that
into
the
annotations.
I
Here,
yeah
I
didn't
know
if
John
was
still
going,
yeah
I
I,
just
I
mean
I.
Wear
it
out
time.
Stuff
I
mean
we're
out
of
time,
but
I
I,
don't
know,
I
mean
I.
Don't
know
why
I
guess.
My
first
question
is:
why
are
we
doing
this
like?
We
never
did
answer
that
and
then
now
I
hear
that
it
feels
to
some
people
like
we're
going
around
in
circles,
which
makes
me
even
ask
it
more
like
we
are.
We
were
just
prepared
to
go
like
fine,
config
media
type,
that's
the
artifact
cool.
B
I
I
G
We
need
artifact
type,
I
I.
Think
I
can
answer
this,
for
you,
I
believe
the
config
media
type
describes
the
config
document
right
historically.
This
is
the
case
today.
G
B
G
And
also
a
meta
object,
and
some
people,
including
myself,
don't
love
that
I'm
fine
with
it,
but
we
I,
don't
love
it
and
so
having
these
two
things
be
separate
means
that,
like
we're
not
flagrantly
making
the
descriptor
and
media
type
thing
like
that's,
why
I
proposed
a
plus
oci
syntax
suffix
for
the
media
type?
It's
like
hey.
G
B
I
B
B
B
I
will
get
a
couple:
PR's
that'll,
be
my
fun
after
hours
project
here
and
thanks
everybody
for
another
hour
I
think
we
made
some
progress
as
much
as
we
went
around
the
circle
a
few
times.