►
From YouTube: OCI Weekly Discussion - 2022-05-05
A
Hey,
I
don't
know
if
anyone
saw
phil's
comment
in
slack
but
sounds
like
he
wants
to
be
a
part
of
that
conversation,
but
I
think
I
feel
like
we're
all
on
the
same
page
about
this
stuff.
But
let
me
know
if
I'm.
B
B
Get
the
chat
window
because
otherwise
people
start
talking,
I
can't
see
it
and
then
I
feel
left
out
of
the
conversation
so
see.
My
mic
is
all
good.
The
two
that
I
had
should
be
quick:
the
registry
versus
repository
terminology.
This
is
in
the
hack
md,
but
I'll
throw
it
here
in
the
chat
message
too.
Just
so
everybody
has.
It
is
basically
looking
at
a
few
spots
in
the
inside
of
all
of
this
that
we
say
registry,
where
I
think
we
actually
mean
repository,
and
so
does.
B
All
right,
so
the
few
places
that
we're
saying
repository
places
like
we're
looking
at
blobs
pulling
blobs
and
it's
giving
a
404
response
not
found
it's
not
that
that
blob
doesn't
exist
within
the
entire
registry.
It
can
just
be
at
the
repository
itself,
doesn't
have
it
locally
mounted,
and
so,
if
you
didn't
do
that
cross
repository
blob
mount,
then
you
wouldn't
see
it.
B
B
Kind
of
like
me,
too,
the
one
place
I
didn't
spend
too
much
effort.
Cleaning
up
was
the
error
messages,
I'm
not
sure
if
that
breaks
anything
if
we
start
changing
some
of
these
messages
or
not
or
descriptions
on
the
codes.
But
there
are
a
few
spots
like
the
blob
unknown.
There's
a
blob
unknown,
really
it's
to
the
repository
not
to
the
registry,
but
I'm
not
too
picky
on
that
so
yeah,
some
of
those
things
out
there
unknown
to
the
registry
yeah.
I
think
a
few
of
these
could
also
be
changed.
B
B
B
Is
because
every
example
in
here,
when
you
look
through
it,
it's
like
okay,
here's
a
name
in
the
name,
space,
the
repository
and
a
tag,
and
they
draw
a
line
like
that.
So
I
was
just
saying
just
to
be
consistent
with
everywhere
else
in
this
document,
where
they're,
using
that
same
term
everywhere,
I
would
just
reuse
that
same
terminology
up
top,
because
otherwise
that
name
makes
no
sense.
Anybody.
B
The
other
one
I
had
out
there,
this
one
might
be
more
contentious
or
might
just
need
more
people
from
the
maintainers
to
actually
chime
in
on
was
that
from
over
on
the
working
group
we're
talking
about
whether
we
need
to
make
a
change.
When
we
push
our
change
up
there,
we
add
new
apis.
B
Do
those
apis
need
to
be
defined
under
extensions
or
do
they
need
to
be
defined
under
the
spec.md,
since
this
is
an
oci
thing
and
I
think
it's
all
up
to
interpretation,
so
I
wanted
to
leave
it
out
there
for
people
that
had
their
various
opinions,
who
thought
what
and
shall
we
pushing
stuff
under
the
extensions
path?
When
we
make
new
changes
out
there,
should
it
be
a
spec
and
they
give
you
an
idea.
The
extensions
is
saying
we
would
have
a
path
up
there
underscore
oci
underscore
refer
something
like
that
underscore.
B
You
know,
slash
slash
all
those
different
things
for
the
path
or
do
we
just
make
a
new
thing
like
we
have
commands
right
now
for
slash,
manifest,
slash
tag
list,
all
the
various
apis
we
have
now.
Can
we
just
make
a
new
api
at
that
level
since
we're
oci?
B
A
A
A
B
D
Not
an
opinion
just
a
question
on
if
someone
can
give
a
history
of
where
the
extensions
came
from
in
the
first
place,.
B
E
So
we
were
trying
to
get
some
set
of
apis
under
v2
and
the
history
is
that
if
we
modified
v2,
we
wanted
to
modify
it
under
a
path
that
would
not
affect
any
clients,
so
anything
under
manifest
and
anything
under
tags
or
those
apis.
We
didn't
want
to
kind
of
like
touch
because
it
has
routing
rules
on
different
proxies
and
whatnot.
E
So
the
main
idea
here
was
that
we
could
create
an
extensibility
option
inside
the
inside
distribution.
There's
also
another
side
conversation
about
capabilities.
I
think
the
camera
is
flickering.
I'm
sorry
about
that
I'll
turn
it
off.
So
there
was
also
a
discussion
about
capabilities
and
how
to
kind
of
discover
what
what
all
of
the
capabilities
the
registries
have.
E
So,
if
you
wanted
to
do
things
like
search
and
if
you
wanted
to
do
things
like
manifest
listing
right,
the
registry
does
not
have
a
manifest
list
api,
but
you
can
expose
those
kind
of
capabilities.
I
google
has
a
different
tag
listing
api.
Acr
has
a
different
tag
listing
api
to
show
you
manifest
and
whatnot,
and
all
these
capabilities
could
not
be
put
directly
on
v2,
because
it
would
break
clients
that
depend
take
dependency
on
the
sdk.
E
That
was
one
one
of
the
historic
reasons,
and
the
primary
motivation
was
that
we
did
not
want
to
go
outside
of
v2
because
of
odd
scopes,
and
things
like
that.
So
these
two
combined
together
the
the
thread
kind
of
summarizes
a
lot
of
different
options
and
naming
schemes
and
places
to
put
and
how
to
define
things
like
pagination,
and
we
took
into
consideration
things
like
being
able
to
do
left
references
or
efforts
and
attaching.
So
there
is
a
lot
of
the
working
group
that
motivation
that
caused
this
as
well.
E
So
one
barrier
or
one,
I
I
think
one
la
one
velocity
or
that
we
can
get
out
of
extensions-
is
that
it
is
marked
as
an
experimental
place.
It
is
marked
as
a
place
for
people
to
kind
of
do
things
and
propose
things
quickly
and
make
the
changes
happen
faster.
E
There
should
be
less
deliberation
because
we
agree
that
extensions
will
give
away
for
not
just
any
cloud
operator,
but
anybody
wanting
to
experiment
under
this
to
offer
this,
for
example,
harbor
or
other
implementations,
can
actually
bring
in
their
own
extensions
of
being
able
to
do
things
like
wonder
what
these
scans
and
formats
they
have.
You
can
attach
different
artifacts,
and
that
is
the
history
roughly
about
extension.
So
it's
a
much
more
higher
velocity
experimental
ground
that
we
can
start
shipping
things
under.
E
But
as
we
call
out
on
the
spec,
if
it's
ratified,
we
can
move
it
to
a
part
under
the
actual
v2
path.
But
should
we
cut
a
new
version
of
the
specification?
Would
be
the
question
if
we
modify
anything
under
v2,
because
that's
new
routes
and
new
types
per
se,
but
extensions,
we've
kind
of
agreed
that
it's
going
to
be
a
little
bit
more
fragile
compared
to
any
other
path
under
v2.
D
Did
did
we
agree
in
the
working
group
session
that
the
the
stuff
under
the
working
group
is
an
experimental
thing
or
something
that
we
feel
should
be
ratified.
E
Right-
and
maybe
I
can
add
that
from
whatever
discussions
we've
had
with
the
aura
side,
we
decided
to
go
with
the
extensions
primarily
because
modifying
the
registry.
Apis
was
not
something
that
we
were
comfortable
with
and
I,
as
a
what
you
say
owner
for
acr,
did
not
want
to
touch
any
of
the
v2
parts.
So
this
gives
us
a
way
to
ship
things
that
who
knows
goes
away.
I
don't
want
to
break
all
the
clients
that
have
kind
of
like
support
right.
E
So
that's
more,
like
an
operator's
point
of
view,
I
think
what
I
think
was.
B
Going
with
this,
though,
just
to
kind
of
tie
off
of
that
because
you
you've
got,
you
started
down
a
path
there.
The
place
I
want
to
look
at
is
differentiating
between
when
we
make
a
change
of
something
like
auras
or
acr
versus
when
we
make
the
change
directly
within
oci
and
distribution.
Spec.
E
Right-
and
there
are
other
projects
like
zot-
that's
actually
leveraging,
I
think
six
or
seven
extensions.
I
was
looking
at
their
pr
as
well,
so
it's
it
is
new
from
from
a
oci
specification
standpoint,
but
it
is
not
a
model
that
I
would
say,
is
not
usable.
It's
up
to
us.
E
I
like
from
the
group
to
decide
whether
we
want
to
go
down
this
path
or
modify
parts
under
other
parts
under
v2,
because
this
is
kind
of
like
a
like
a
home
in
some
way
for
other
projects
to
come
out
and
the
working
group
can
be
ratified
directly
into
into
we
too
or
manifest.
If
we
see
that's
the
right
place,
I'm
not
saying
we
should
go
either
way,
but
just
to
make
sure
that
references
don't
break
any
other
implementations
either.
E
We
have
to
decide
to
cut
a
new
version
of
spec
if
we
modify
any
other
parts
of
the
oci
or
we
quickly
add
this
working
group
under
as
an
extension,
oc
extension
and
then
for
the
next
year
or
two
kind
of
like
see
how
it
goes
and
modify
the
spec
accordingly
either
way
it
seems
so
it.
C
I
don't,
I
don't
think
we
need
to
modify
it.
I
don't
think
we
need
to
version
the
spec,
but
we
we
can.
We
certainly
can.
I
think,
the
way
to
get
around
considering
this.
A
breaking
change
is
to
say
that,
in
version
1.2
of
the
spec
or
whatever
1.6
of
the
spec,
to
say
that
implementations
may
implement
the
refers
api
as
described
here,
and
if
you
implement
it,
it
must
do
this.
C
But
that
way
when
1.6
with
references
comes
out,
ecr
is
not
on
non-compliant
on
that
day
or
acr
is
not
non-compliant
on
that
day.
They
just
don't
take
the
option
to
support
the
references
api.
So
that
way,
it's
not
a
breaking
change.
Even
if
we
you
know
we
can,
we
can
cut
a
version
if
we
want
to
cut
a
version.
That's
fine,
but
it
won't
be
a
breaking
change,
even
no
matter
what
it's
not
like.
Okay,
it's
not
like
in
performance
for
registries
that
don't
do
references
they've
just
chosen
not
to
support
references
in
the.
E
Right
it
can
be
a
minor
version
bump,
or
at
least
the
the
other
thing
is,
if
you
are
getting
into
the
references
or
the
first
conversation,
the
paths
for
the
references
actually
attach
onto
the
manifest
itself,
which
is
different
from
the
rejects
parsing
or
the
the
uri
parsing.
That's
there
in
the
registry.
Currently
you
look
at
two
segments
back
and
then
you
kind
of
like
follow
off
that.
But
if
you
add
multiple
segments
over,
for
example,
manifest
digest
slash
reference.
That
is
a
a
different
parsing
logic
and
trust
me.
E
We
did
both-
and
I
know
the
history
of
this-
that's
why
I'm
telling
you
which
way
we
want
was
something
we
not
want
to
kind
of.
Like
think
about
right.
E
We
actually
went
to
the
first
part
when
we
kind
of
prototyped
orange
just
to
give
you
history
on
that,
and
it
was
discussed
as
to
is
this
the
path
that
we
want
to
take
where
we
do
a
double
look
up
backwards,
or
should
we
just
stick
under
the
extensions
model
which
was
slightly
more
similar
to
what
catalog
and
the
other
apis
were
because
underscore
is
a
kind
of
reserved
non-repository
name
and
that's
the
delimiter.
So
it
was
more
of
a
technical
background
to
why
that
path
was
chosen.
E
So
I.
C
Think
that's
helpful.
I
mean
the
the
proposals.
Url
format
is
not
set
in
stone
either
right
we
can.
We
can
talk
about
all
of
that.
I
think
the
main
question
of
whether
the
end
result
of
the
working
group
should
be
a
distribution,
spec
change
under
v2
or
an
extension.
I
think
it
has
to
be
a
v2
thing.
We
can
experiment
in
extensions,
we
can
do
we
can
we
can
prototype
in
extensions
and
we
should
and.
C
Can
even
keep
that
implementation
at
the
experiment
path
at
the
extension
path
you
know
forever,
but
I
don't
think
we
are
proposing.
I
don't
think
the
end
result
of
all
of
this
is
we
provide
an
extension
that
people
can
implement
or
not,
and
here
is
the
spec
for
that
extension
like
why
not
just
make
that
a
v2,
a
new
v2
url
that
registry
operators
can
implement
if
they
want
to.
If
the
problem.
C
It
sounds
like
the
real
technical
problem
you're
describing
is
having
digest
slash
references
or
digest
whatever
may
break
url
handling
in
clients
and
servers.
I
think
that's
a
point
to
bring
up
in
the
working
group
we
can.
We
can
talk
about.
A
A
C
C
Yeah
yeah.
Sorry,
I
that's
that's
me
speaking
in
precisely
but
a
non-extension,
a
quote:
I'm
making
finger
quotes,
but
you
can't
see
a
real,
a
real
distribution
path
instead
of
a
an
extension
we
should
play
in.
B
Think
yeah
yeah,
so
real
quick
one
of
the
reasons,
because
I
can't
raise
my
hand
like
everybody
else.
I
think
one
of
the
comments
put
out
there
on
proposal
b
was
that
we
had
the
references
showing
up
at
the
end
of
this
string
here,
where
I
changed
that
order
around
when
I
put
it
over
on
proposal
d,
just
to
move
references
in
place
of
wherever
you
would
have
manifest
or
tag
list,
and
something
like
that
to
make
that
parsing
similar
between
all
the
other
api
calls
out.
There
go
ahead.
Nisha.
D
Yeah
so
now
I'm
confused
because
brandon
you
had
shown
that
a
version
bump
is
not
something
a
registry
can
handle
unless,
unless
the
registry
was
modified
to
unless
the
code
is
modified
to
check
whether
there
is
a
there
is
a
b2
or
something
like
that.
B
This
depends
on
what
version
we're
talking
about,
and
so,
if
we're
talking
about
the
media
type
string
itself
inside
of
one
of
these
things,
that's
going
to
be
a
problem.
If
we're
talking
about
distribution,
spec,
cutting
in
their
new
release
and
then
validating
different
registries
out
there
comply
or
don't
comply
with
it.
That's
okay!
I
think.
B
Yeah
no
no
worries
because
it
brings
up
another
thought
that
I
had,
which
was.
Does
it
make
sense
that
we
can
just
say:
hey?
A
registry
can
be
compliant
with
the
1.1
of
distribution
spec
and
not
compliant
with
1.2
of
the
distribution
spec.
Where
we
add
this
new
feature
out
there
and
then
users
out
there
can
say:
hey
I've
got
this
new
code.
I
want
to
get
the
latest
and
greatest
registry.
Let
me
get
somebody:
that's
got
version,
1.2
compliance.
F
F
B
E
Even
though
it's
part
of
the
oci
specification.
So
I
think
registries
are
have
the
flexibility
to
ignore
or
reject
parts
that
it
doesn't
understand.
But
spec
itself
doesn't
stop
you
from
putting
any
arbitrary
media
type
in
there.
F
B
B
E
B
Yeah,
when
registries
look
for
how
to
parse
a
manifest,
they
just
go
through
a
like
a
select
statement
in
there
and
they
look
to
see
all
the
different
media
types
they
understand
and
if
it
doesn't
know
how
to
parse
that
manifest,
then
it
doesn't
know
how
to
parse
the
objects,
the
manifest
references
and
it
can't
validate
anything
at
that
point.
F
D
I'm
sorry
to
interrupt
I'll
wait.
D
Okay,
so
the
reason
I
am
pulling
at
this
thread
is
because
I'm
still
unable
to
understand
why
there
is
so
much
hesitancy
to
bump
versions,
whether
it's
on
the
registry
api
or
whether
it's
on
a
manifest,
because
after
all,
this
is
a
specification.
D
D
Well,
I
mean
I'm,
I'm
done
putting
my
point
out
there.
This
is
this
is
a
thing
that's
been
at
the
back
of
my
head
throughout
this
whole
talking
point:
I'm
I'm
still
not
able
to
understand
where
that
yeah.
C
Think
I
think,
there's
a
practical
concern
with
that
clients.
Take
a
long
time
to
roll
out
registries
take
a
long
time
to
roll
out
and
if
you
say
you
know,
schema
version
three
or
man
media
type,
v3
things
like
that
it
takes
it
takes
quite
two
years
to
roll
out,
basically
anything
and
it
takes
gcr
months
to
roll
out
anything.
I
can't
speak
for
anybody
else,
but
there's
a
practical
like
you,
don't
you
don't
want
to
just
proliferate
versions,
there's
also,
like
version
compatibility
between
things.
Can
I
push.
D
A
D
You
can,
for
example,
use
a
v2
manifest
and
push
it
to
a
v3
endpoint
and
if
you
wanted
to
push
it
to
a
v2
endpoint,
there's
a
failure
mode
that
or
or
there's
a
notification
that
the
registry
can
send
out.
Basically
saying
you
know:
actually
you
should
push
it
to
the
v3
endpoint,
not
the
v2
endpoint
or
we
do
not.
I.
C
Mean
yeah,
then,
then,
clients
have
to
understand
what
that
means.
They
have
to
like
signal
that
to
users
they
have
to
either
fail
with
a
useful
error
message
or
you
know,
fall
back
and
do
that
themselves
like
and
and
clients
will
take
a
long
time
to
do
it
and
clients
may
never
do
it.
If
there's
no
reason,
if
there's
no
business
reason
to
hire,
you
know
pay
an
engineer
to
do
this
work
then
they'll.
Never
do
it.
F
C
Yeah
there's
there's
like
five
different
versions.
We
could
rev
right
like
we
don't
I
don't.
I
don't
think
we
want
to
change
the
schema
version
or
the
media
type
version.
I
think
we
should
cut
a
new
version
of
the
spec
and
say
this
is
distribution
1.2
now
with
now
with
refers,
but
on
day
on
the
day
that
1.2
is
cut
with
referrers,
that
every
registry
that
in
existence
that
we
know
of
is
already
compliant
but
they're
already
conforming
to
it,
because.
C
Yeah
I
mean
yeah.
I
think
this
always
comes
up.
When
we
talk
about
bumping
versions,
it's
not
conceptually
impossible
to
bump
a
version.
It's
practically
difficult
and
needs
to
be
motivated
by
a
big
thing
and
right
right,
distribution.
F
C
D
Well,
so
it
is
helpful
as
far
as
like
practicality
is
concerned,
but
I,
but
the
reason
why
we
created
the
working
group
in
the
first
place
was
because
we
found
we
have
a
business
need
for
it,
and
maybe
you
know
the
next
step
is
to
actually
go
ahead
and
cut
the
release
and
wait
until
you
know
we
we
get
feedback
on
from
implementers,
saying:
okay,
you
have
this
new
stuff,
it's
got
all
of
these
it.
It
says
it
has
all
these
features.
How
do
we
access
those
features?.
F
C
Yeah,
I
think
I
think
that's
what
she
means.
I'm
not
worried
at
all
about
bumping
distribution,
spec
like
like
having
a
new
version
of
the
distribution
spec.
I
don't
I
don't
I'm
not
worried
about
that
at
all,
because
we
can
make
that
backwards
compatible
and
when
1.2
comes
out,
everything
is
automatically
conformant
with
it.
So
nobody
has
to
do
anything.
C
I
do
worry
about
bumping,
media
type
versions
or
bumping
schema
versions,
because
that
is
a
small,
a
small
diff
in
the
spec,
but
a
massive
churn
of
work
for
clients
and
registries
and
users
with
almost
no
benefit,
and
I
don't
even
think
we're
talking
about
that.
I
don't
even
think
we're
definitely
like
proposing
that
we're
just
saying
we'll
make
some
changes
to
the
distribution.
Spec,
we'll
cut
a
release.
C
D
So,
just
to
just
to
be
certain
jason
if
a
client
wanted
to
implement
the
referral
spec
in
the
distribution.
D
If
they
wanted
to
implement
that
what
would
be
stopping
clients
from
saying
okay,
we
check
for
schemas,
2
and
schemas
3.
C
Because
registries
dockerhub
today
will
never
respond
with
a
with
a
schema
version.
Three,
like
I
see
you,
there
is
no
way
to
get
docker
hub
today
to
respond
with
schema
version
three,
as
far
as
I
know,
but
if
it
was
schema
version
two,
but
if
you
go
hit,
the
slash
refers
api
or
whatever,
whatever
endpoint
we
end
up
describing
and
if
404s,
then
you
know
they
don't
support
this
version.
Do
the
fallback
in
proposal
e
and
do
it
that
way
and
if
it.
C
C
D
B
So
right
now,
when
we
do
it,
on
marshall,
the
manifest
we're
going
out
there
and
saying,
let's
get
the
mappings
of
these
media
types
and
those
have
been
registered
individually
against
specific
strings
and
so
they've
got
whatever
that
media
type
is
there,
which
is
this
one
specific
string
is
mapped
to
this.
One
function,
don
marshall,
when
you
bump
that
version
you're
really
saying
that
version
3
is
incompatible
with
version
2.
At
that
point,
you
can't
use
the
version
2
on
marshall
or
to
on
marshall
version,
3
manifest.
B
E
Without
forgetting
the
vulnerability
issue
that
came
where
we
actually
made
media
type
mandatory
that
broke
all
the
the
marshalling
and
disambiguation
between
oci
types,
so
the
marshall
part
alone.
The
line
that's
showing
here
was
not
the
is
probably
one
portion
of
how
we
could
disambiguate
manifest,
but
there's
more
to
it
than
just
looking
at
the
media
type
is
what
we
had
to
go
through
when
we
had
made
the
media
type,
as
I
should,
because
oci
by
default
would
so.
E
This
is
how
you
discover
the
media
type,
but
if
the
media
type
was
not
there,
there
was
another
discovery
mechanism
also
right.
So
all
I'm
trying
to
say
is
that
whether
we
bump
the
manifest
media
type
or
not,
there's
going
to
be
work
to
make
sure
that
we
parse
references
off
a
particular
form,
even
if
it's
in
the
same
media
type,
that
doesn't
make
sense,
I
mean.
E
This
distribution
is
one
implementation,
but
I
just
think
there's
more
to
it
than
just
falling
off
on
the
media
type
itself,
depending
on
the
fields
that
do
exist.
E
On
history,
so
so
the
media
type
itself
was
made
mandatory
as
a
part
of
the
specification
bump
and
registries
before
didn't
even
look
at
the
media
type
to
sometimes
determine
what
the
type
was.
E
D
This
method
I
mean
in
general
just
generally,
like
you
know,
evaluating
dictionaries,
is
not
safe,
so
I'm
wondering
if
we
are,
if
we
are
focusing
on
the
fact
that
you
know
if
we
are
like
very
much
focused
on
implementation,
rather
than
what
improvements
we're
trying
to
make.
E
No,
I
think
jason's
point
is:
there
are
a
lot
of
clients
with
the
string
hardcoded
and
they
have
parsing
logic
that
kind
of
like
forms.
Okay,
these
are
the
blobs.
These
are
the
layers.
If
we
change
that
schema,
then
there's
a
lot
of
forking
code
that
needs
to
kind
of
like
create
a
yet
another,
manifest
workflow
that
that
seems
to
be
the
challenge
that
I'm
I'm
hearing
from
the
hesitancy
of
bumping,
the
image
version,
distribution
version.
I
don't
think
there's
any
concern
in
bumping
up
because
it
doesn't
affect
any
of
the
persistent
data.
E
D
No
it
it
makes
sense
to
me
it's
just
it's
just
a
crazy
reason
in
my
head.
Anyway,
again
I
I
guess
I
haven't
been
in
this
community
for
very
long
to
be
able
to
say
that
okay,
this
is,
I
mean,
that's
a
reasonable
thing
to
say
or
not.
I
come
from
a
completely
different.
E
B
C
I
was
just
going
to
say
I
want
to
clarify
something.
Sanjay
said:
I'm
not
worried
about
bumping
the
image
spec
version,
but
by
like
bumping,
you
know
image,
spec
version,
1.1
or
1.2
or
1.3.
This
is
not
the
schema
version
in
the
image
spec
manifest,
and
this
is
not
the
media
type
oci
dot
manifest
plus
v2
whatever,
but
right
they
knew
cutting
a
new
version
of
the
image.
Spec
is,
I
think,
a
goal
of
the
working
group
to
say
to
document
to
include
documentation.
C
You
can
include
references
and
if
they,
if
you
do
include
references,
they
should
look
like
this.
They
must
look
like
this
and
this
is
what
they
mean.
C
Yeah
and
and
yeah
yeah,
I
gotta,
run
a
little
early,
but
this
has
been
super
helpful
thanks.
Everyone.
F
D
So
can
I
try
and
summarize
what
we've
maybe
agreed
upon
it
seems
that
we're
totally
fine
cutting
the
new
version
of
distribution
spec
with
the
referrals,
and
we
will
slowly
include
the
other
changes
as
and
when
clients
adopt
the
new
version.
The
new
referral
spec.
F
I
think
that's
a
good
direction,
we
would
see
the
proposal
and
you
know
analyze
it
in
deep
detail.
B
Sorry
I
was
on
mute
there,
so
I
just
wanted
to
clarify,
since
I
was
looking
up
some
of
the
media
type
stuff
earlier
and
might
have
missed
some
of
the
points
being
made
when
we
come
to
looking
at
this
we're
saying
it
doesn't
need
to
go
as
an
extension.
We
just
want
to
put
it
directly
within
the
reference
api.
D
I
think
that
was,
I
think
that
was
what
it
is.
Cutting
a
new
version
like
adding
a
new
pack
api
path
in
spec.md
is
fine.
It's
not
going
to
affect
anyone,
because
all
every
anyone
who
is
operating
a
registry
right
now
is
still
oci
conformant
and
they
are
open
to
adopt
the
new
changes
if
they
want
to
or
not,
they
can
inform
their
clients
that
this
is
how
you
use
the
new
changes
if
they
want
to
or
not
it's
up
to
them.
B
Yeah
part
of
the
value
of
the
whole
extensions
api
was
that
registries
that
want
to
put
their
own
pads
could
put
their
impact
somewhere
that
oci
wouldn't
later
step
on
them
and
break
them
in
the
future,
and
so
they
knew
that
if
they
put
their
stuff
under
acr
or
as
whatever
the
path
is
they're
building
their
functionality,
they're
safe
within
that
namespace
to
do
whatever
they
want
to
do.
I
know
that
oci
isn't
going
to
come
up
later
on
and
just
dump
the
path
right
on
top
of
them.
Well,.
F
F
The
oci
extensions
would
be
a
way
for
you
to
do
that.
Right,
start
it
out,
try
it
get
some
registries
to
use
it
and
apply
that
endpoint,
and
then
you
know
once
it's
you
know
gold.
If
you
will
right
or
gone
through
some
minor
minor
revisions,
then
you
would
promote
it
to
you
know
an
actual
spec
must-have
version.
B
Yeah
no
and
it's
something
I've
seen
when
I
was
looking
at
kind
of
the
comment
here
of
I
know
vincent
said
in
one
of
these
little
sentences,
but
instead
of
reading,
while
everybody's
listening,
what
I'm
saying
I
can't
read
and
speak
at
the
same
time
since
I
knew
that
was
a
point
that
was
made
there.
B
F
B
F
F
B
F
E
I
think,
if
there's
not
going
to
be
any
change
for
like
three
to
four
years
and
directly
proposing
it
under
under
v2,
reference
actually
makes
sense.
But
if
you
think
that
the
api
is
going
to
rev
when
you're
going
to
change
parameters
or
change
the
schema
or
anything
like
that,
then
the
extension
makes
sense
to
kind
of
quickly
iterate.
E
E
They
care
about
their
care
about
their
customers.
They
should-
and
I
think
that's
a
conversation
that
they
should.
Individual
operators
should
kind
of
think
about
like
if
they
don't
want
to
break
folks,
they
keep
the
extension
around
or
they
slowly
migrate
them.
I
can
give
an
example
of
one
discussion
that
we've
had,
which
is
supporting
like
this
is
not
got
anything
into
the
auras
or
acr,
but
we
had
an
sdk
released,
a
bunch
of
apis
that
are
unique
to
us
and
we
had
to
change,
add
a
bunch
of
new
fields.
E
It
was.
It
was
a
breaking
change
in
many
ways
and
it's
a
hard
conversation
and
I
I'm
very
scared
of
defecation,
but
if
you
have
to
do
it
that
should
be
upon
how
operators
want
to
follow.
I
don't,
I
think,
there's
an
option
that
we
can
choose.
E
But
if
there's
no
change
that
we
anticipate
to
the
reference
api,
for
example,
we
don't
break
the
filtering,
we
don't
we
don't
add
more
things
at
a
very
fast
pace,
then
just
putting
it
under
the
registry
makes
like
v2
slash.
Reference
makes
sense,
or
we
do
slash
name,
but
that
that's
what
I
think
what
mike
is
kind
of
asking.
If
we
can
get
the
working
group
to
make
a
proposal
and
see
where
it
lands,
god.
D
So
extensions
first
and
then
cut
the
spec
cut,
a
new
version.
B
E
I'm
actually
thinking
of
the
next
working
group
coming
along
and
saying
that
hey,
we
want
to
modify
the
spec
and
we
kind
of
like
set
press.
It
and
say:
hey,
go
through
extensions.
Do
this
first,
it
might
take
you
a
short
time
by
the
time
the
spec
is
ratified.
You
can
move
it
under
because
that
kind
of
sets
a
clear,
fast
path
for
the
next
one
to
come
along.
D
So
I
guess
my
next
question
is:
do
we
have
any
like
framework
as
to
how
early
adopters
can
start
implementing
and
playing
around
with
the
spec
beyond
josh's
oci
playground,
thingy.
D
Yeah
yeah
yeah,
I
mean,
but
in
general,
so
we
have
it.
It
seems
like
the
path
to
acceptance
is
experiment
with
it
show
us
your.
You
know:
each
working
group
experiments
with
the
with
it
and
comes
up
with
the
standardization
of
how
things
get
done.
Make
it
into
us
a
spec
change,
submit
the
spec
change
to
wherever
the
wherever
you
need
to
submit
and
repeat.
E
Yeah
I'm
just
trying
to
follow.
The
question
is:
is
that
are
you
like
just
clarifying
or
is
it
like
a?
Is
there
any
no.
D
No
I'm
trying
to
clarify,
like
you
know,
so
suppose
we
were
to
do
that
suppose
the
working
group
was
to
say,
like
okay,
we're
going
to
experiment
it
with
this
for
a
little
while
what
does
that
look
like
to
developers
just
come
in
start
making
changes
to
something
doing
demos?
B
I
think
part
of
the
value
of
having
the
playground
out
there
is
that
we
can
start
capturing
a
bunch
of
the
different
implementations
that
people
have
put
together
of
this,
whether
it's
a
fork
or
whether
the
upstream
project
just
implements
it
directly.
And
then
people
can
play
against
those
and
then
submit
their
own.
D
E
I
I
I
can.
I
can
maybe
talk
about
distribution,
I
mean
we
we
want
to
probably
like
get
josh
is
working
on
zot.
I
had
a
chat
with
josh
if
he
needs
help
kind
of
implementing
our
distribution,
and
if
you
want
to
do
that,
we
can
put
a
reference
implementation
on
distribution.
Also,
distribution
is
the
other
project
right,
so
we
can
look
at
both
and
then
whichever
works,
and
it
shows
that
multiple
scenarios
supported
it.
It
makes
the
makes
the
case
for
when
you
bring
it
to
oci
maintainer
saying
that
hey.
E
This
is
what
we
have
these
other
sample
implementations
and
it
looks
good,
and
that
builds
confidence
in
some
way
and
if
registry
operators
throw
it
out
there,
then
it's
kind
of
like
a
much
more
stronger
set
of
examples
to
kind
of
like
go
by
like
there's
precedence
in
making
that
directly
into
the
specification.
A
You
want
to
give
the
spec
maintainers
like
very
little
room
to
like
not
accept
the
changes,
so
I
think
as
much
as
much
that
we
could
demo
and
say
this
works,
and
this
has
been
fleshed
out
across
multiple
projects
and
servers
and
clients.
I
think
the
better
I
will
say,
though
I
think,
like
you
know,
if
someone's
working
on
zod
and
someone's
working
on
distribution
we
should
align
on
the
working
group,
should
align
on
whether
it's
using
extensions
or
like
this
and
that
the
upgrade
path.
B
Yeah,
I
think,
having
this
discussion
here.
I
can
submit
some
pr's
later
this
week.
Just
to
say
here
are
some
of
the
changes
we
it
looks
like
we're
agreeing
with
and
in
addition,
I'm
thinking
through
the
sample
implementations
go
container
registries..
I
can
do
reg
client.
If
we
get
distribution
distribution.
That's
awesome!
B
B
E
I
want
to
officially
state
my
support
for
the
working
group
because
I
think
that
was
brought
up
in
a
couple
of
issues.
E
We're
spending
significant
amount
of
time,
making
sure
that
this
thing
happens,
because
in
the
end,
customers
want
to
store
different
things
right,
like
signature
scans
and
all
that
stuff.
So
I
will.
I
want
to
probably
like
help
there
as
much
as
possible,
but
everybody
has
challenges
and
priorities
and
we
need
to
figure
out
how
we
can
make
this
happen.
So
just
to
put
it
on
the
record.
At
least
my
support
for
the
working
group
is
definitely
there.
B
A
D
D
B
B
F
A
little
bit
about
the
the
path
on
this
after
you
after
the
work
group,
gets
us
ready
and
it's
ready
for
distribution.
I
think
we've
got
some
caps
to
do
in
kubernetes
around
this
as
well.
As
you
know,
some
container
runtime
changes
to
the
cry.
How
do
we
validate
this
stuff?
Where
do
you
want
to
check
these
extension
points
that
they're
available?
And
what
about
you
know?
What
results
can
we
get
out
of
it
and
and
start
to
make
use
of
it
right
in
the
patterns.
B
Yeah,
what
I'll
start
with
is
just
in
proposal
and
proposal
e
I'll
just
put
two
entries
in
there.
One
is
the
long
term
vision
of
where
we
hope
to
see
this
and
then
the
short
term
I'll
put
a
underscore
oci.