►
From YouTube: OCI Weekly Discussion - 2022-12-08
A
B
A
C
D
D
Might
be
worth
I
think
I'm
hearing
a
lot
of
questions
about
sort
of
how
we
tell
if
a
registry
is
implemented,
oci,
1.1,
I,
think
you
guys,
you
all
have
a
issue
on
this.
B
Yeah
we
we
have
a
bunch
of
places
where
we
need
to
copy
stuff
around
and
client
tooling,
specifically
so
I
think
this
was
shoest
team,
who
kind
of
placed
it
on
Slack.
B
I
think
my
recommendation
to
Laura's
folks
was
don't
change.
Manifest
types
automatically
just
defeat.
The
purpose
of
content
accessibility,
so
stick
with
one
type
and
portability
between
the
two
types
are
not
something
that
we
assume.
For
example,
you
don't
convert
between
Docker
and
oci.
Automatically
I
mean
you
can,
but
you
just
don't
because
then
the
index
and
everything
kind
of
like
gets
messed
around
the
the
question
was
less
about
portability.
It
was
whether,
from
the
registry
we
can
deterministically
decide
what
to
use.
B
For
example,
the
use
case
right
now
is
push
and
fail.
It
seems
bad
right,
you
don't
want
to
try
pushing
a
manifest
and
then
failing
the
referral.
Api
doesn't
deterministically.
Tell
you
whether
it's
supported
or
not.
B
If
the
repository
doesn't
exist,
you
have
to
look
at
a
sub
status,
so
the
there's
some
holes
in
the
the
discovery,
the
discoverability
of
these
capabilities
and
I,
think
initially
we
wanted
to
make
sure
that
this
was
not
a
part
of
the
working
group
but
being
able
to
just
define
whether
the
registry
supports
a
version
was
the
ask
whether
it's
reference
or
any
new
API
or
the
support
of
a
new
manifest.
B
A
A
What
do
you
want
to
do
and
if
the
user
says
Hey
I
want
to
push
with
this
manifest
type
I'm,
not
second
guessing
them,
I'm,
not
trying
to
Auto
upgrade
or
downgrade
or
anything
like
that
I'm
just
saying
whatever
you
give
me
I'm
going
to
do
everything
you
gave
me
doesn't
work,
then
it
fails,
and
so
I
I
do
look
at
the
push
and
fail
and
just
say
well
if
it
fails,
it
fails
at
that
point.
But
it's
because
I
moved
that
decision
back
from
an
auto
detecting
what
the
registry
has
to.
B
Okay,
that's
kind
of
what
I
stopped
as
well
like
there's
got
to
be
a
flag
or
something
in
the
user
experience
well,
but
I
think
the
question
is:
should
the
clients
have
a
way
that
they
can
determine
any
workflow
can
determine
this,
irrespective
of
what
the
user
gives.
If
you
have
a,
if
you
have
a
system,
do
you
want
the
system
to
be
able
to
tell
its
version,
or
do
you
want
the
system
to
have
clients
input?
What
version
that
it
wants
to
communicate
to
like.
A
B
A
C
But
this
doesn't
make
sense
to
me
what
you're
saying
you
know,
sort
of
like
Peak
and
poke
kind
of
way
of
building
clients.
Is
it
works,
I
think
when
we
get
to
having
sort
of
abstractions
and
libraries
and
sdks
and
another
tooling,
that's
bundled
you
I
think
having
something.
That's
a
little
more
I
wouldn't
say
sophisticated,
but
just
as
a
little
more
logically
pokable
like
I
do
like
I
like
that
sort
of
analog
of
just
saying
like?
Does
it
do
this?
Does
it
do
that?
Let
me
prove
it.
C
I
think,
there's
also
value
in
version
software
I
mean
to
say
like
I,
don't
trust
aversion,
that's
fine,
I
mean
a
lot
of.
My
career
has
been
built
on
trusting
versions,
so
I'm
kind
of
okay
with
that
and
I
think
in
this
case
it's
it's.
It
is
where
we're
stuck
where
we
we
could
say
well.
This
is
1.0
until
it's
1.1,
so
whether
you
implement
parts
of
it
or
not
as
irrelevant
a
client
can
say
no,
it's
1.0
we're
doing
this
other
way.
C
Now
you
have
1.1
now
we
know
you
have
artifacts
and
it
refers
API
thanks.
We
could
go
with
capabilities
right
and
we've
seen
things
like
this.
Through
the
years
you
have
a
you,
know,
sort
of
a
bit
mask
or,
or
you
know,
some
Json
blob
that
lands
and
gives
you
strings
of
the
things
that
that
it
that
it
supports
whatever
that
is,
then
you
can
actually
kind
of
be
more
granular
with
it.
C
I'm
not
sure
I
love
that,
because
it
is
a
versioned
API,
there's
no
1.1
a
and
1.1
final
right,
I
mean
we're
just
going
to
say,
is
1.0
and
there's
1.1,
but
we
don't
really
even
have
that
yet
and
so
there's
really
no
way
of
knowing,
and
so
you
kind
of
poke
at
the
refers
API
and
say:
okay,
that
exists.
We
assume
that
artifacts
are
there.
We
can't
because
it's
in
the
spec
they're
they're
not
tied
right
so
so
I
think
that's
the
problem.
C
A
Oh
I'll
stop
Shore,
saying
we
don't
have
a
version
because
we
do
have
the
conformance
checks.
So
if
you
pass
all
the
conformance
checks,
you
get
whatever
shiny
badge
that
says:
hey.
This
registry
actually
supports
1.1.
It's
not
coming
out
of
the
registry
itself,
it's
like
a
actual
test
and
then
we
record
that,
as
part
of
our
part
of
the
oci
conformance
results
and.
A
There
there
is
not,
and
so
that's
what
I'm,
what
I'm
getting
at
is.
We've
got
this
from
the
perspective
of
a
user.
Can
look
at
a
registry
and
see:
is
the
registry
I'm
working
with
supporting
this
stuff,
but
we
don't
have
something
from
the
client
API
level
to
be
able
to
query
this
and
I'm
I'm
hesitant
to
put
too
much
value
in
there
I'm
just
going
to
pull
another
like
a
sample
out
out
there,
because
I'm
I'm
thinking
of
a
whole
lot
of
things
can
go
wrong.
A
One
I'll
put
two
examples
out:
one
you
could
have
some
kind
of
version
API
and
one
person
could
take
looking
at
the
version
and
decide
I'm
going
to
push
that
refers,
digest
and
whatnot
based
off
of
that,
and
it
decides
okay
well,
I
see
this
post
already
have
this
refers
API,
so
I'm
not
going
to
push
that
fallback
tag,
and
you
can
have
another
tool
that
actually
goes
and
does
the
Poke
and
looks
and
sees
this
API
actually
respond?
No,
it
doesn't
respond.
Let
me
manage
that
digest.
Tag.
A
You've
got
this
thing
now
in
two
different
states.
You've
got
something
that
actually
has
the
tag,
something
doesn't
have
the
tag
and
depending
on
which
of
the
different
states.
The
registry
is
in
you've
got
like
four
different
possibilities.
There
I
think
you
know,
depending
on
where
you
are
because
you
have
two
variables
at
that
point
and
two
clients,
so
it
can
get
in
some
very
odd
and
consistent
states
that
I
I
get
concerned
of
and
I
kind
of
hesitate
back
from
and
I'll
hold
off
of.
My
second
example
for
Michael
jump
in.
D
I
think
like
I
guess
when
you
say
that
my
my
mind
goes
sort
of
isn't
that
what
the
specs
are
for
like?
Is
it
if
we,
if
we're
sort
of
saying
We're
Not
Gonna?
If
someone,
if
originally
said
their
one
to
one
compliant
but
then
doesn't
support
that
like?
Why
do
clients
need
to
necessarily
care
like
that's,
that's
not
compliant
with
the
spec,
and
we
would
encourage
people
not
to
do
it.
D
But
if,
if
someone
is
going
to
implement
an
oci
registry
and
not
follow
the
spec
like,
we
shouldn't
be
designing
Tools
around
that
possibility,
and
if
we
do,
we
end
up
with
tools
that
have
like
all
of
this
fallback
and
all
this
extra
code
that
checks
conditions
that
shouldn't
you
know
shouldn't
need
to
happen,
because
people
should
Implement
against
the
spec.
And
yes,
there
will
always
be
small
pieces
where
things
are
maybe
not
implemented
correctly,
but
vinegar.
A
A
It's
not
for
the
artifact
manifest
so
yeah.
If
you're
asking
do,
they
need
to
know
if
they
can
push
the
artifact
manifest
or
not
yeah,
we
don't
have
anything
there,
because
I've
personally,
I've
always
delegated
that
as
a
something
that
end
users
are
probably
gonna
need
to
step
in
at
some
point
make
that
decision
as
an
input
on
their
side.
A
I'll
throw
the
second
example
out,
which
is
that
you
can
throw
out
all
the
versioning
and
say:
hey.
We
support
version
1.1
of
oci
or
something
but
I,
see
Ram
Kumar
here
so
I'll
pick
on
saw
right
now,
which
is
that
last
check
stop,
doesn't
support
any
of
the
docker
manifest
it
supports
all
the
UCI
ones,
but
doesn't
support
the
docker
one.
So
if
you
try
to
push
a
Docker
manifest
to
sought
right
now,
it'll
say
under
manifest
and
that's
a
very
it's
an
unexpected
behavior
from
anybody.
A
That's
used
to
working
with
container
images
from
the
past
because
I
think,
probably
you
know,
nine
percent
of
our
images
are
still
probably
all
still
out
there
at
the
docker
media
types.
So
I
I'm
always
worried.
There's
gonna
be
an
edge
case
out
there.
Where
we
can
say:
hey,
you've
got
this
version,
all
of
our
checks
say
they're
fine,
because
they
actually
do
support
all
the
oci
specs.
But
then,
from
the
user
standpoint
the
user
tries
to
use
it.
They'll
hit
these
edges
they're,
just
they
just
weren't,
expecting
just
for
weird
issues.
C
Think
that's
what
makes
a
good
specification
what's
what
makes
a
healthy
Community
standard,
I
think
from
again
what
you're
saying
totally
makes
sense:
I,
don't
want
to
repeat
myself,
but
I
think
you
know
for
when
we're
building
sort
of
automation
behind
managed
services
that
are
like
these
large
at
scale
features
that
we
want
to
implement.
It
becomes
more
difficult
to
say
you
know,
let's
sort
of
poke
at
this
and
we'll
try
a
push.
I
mean,
for
example,
oci
artifacts,
determining
whether
a
registry
supports
them.
We
could
literally
bundle
one
up.
C
Send
it
look
at
the
error
code.
We
get
back
and
now
we're
deterministically
know
like
okay,
that
endpoint
works
or
not
I.
Don't
want
500
000
clients
doing
that.
To
me,
a
minute
like
I,
just
that's
kind
of
part
of
the
thing
here
is
I
would
much
rather
just
return
a
value
to
a
client
say:
I
I
support
this
I.
Don't
support
that
so
I
guess
that's!
The
question
is,
is
a
does?
Do
we
as
a
as
a
community
here
think
that
that's
needed
and
B?
How
should
we
do
it?
Would
it
be
capability
strings?
C
Would
it
be
just
a
version,
something
right,
because
right
now,
I
think
you're
right
most
stuff
that
has
been
introduced
here
has
been
an
API
endpoint,
so
you
can
just
poke
it
and
if
it
doesn't
exist,
it
doesn't
exist.
The
OCR
effect
is
this
is
a
new
thing
right.
So
I
guess
that's
I'd
like
to
understand
that
like
do,
we
think
this
is
a
problem
or
not,
and
how
would
we
like
to
address
it.
A
A
B
I
think
we've
stepped
away
from
those
CR
body
being
a
standardizing
or
a
list
of
all
conformant
Registries
kind
of
thing
we
didn't
want
to
kind
of
like
aggregate
all
the
media
types
and
all
that
right.
So
the
conformance
test
is
a
is
a
good
place,
but
I,
don't
think
expecting
clients
to
depend
on
the
conformance
test.
To
say
whether
the
registry
Falls
in
a
bucket
of
support
is
is
a
model
that
I
wasn't
sure
whether
we
wanted
to
align
with
that,
because
we.
A
C
Yeah
I
think
I
I
I,
don't
Sanjay
I,
don't
want
to
restate
what
you
said.
I
think
I
agree
with
what
you
said
and
then,
if
I'm
saying
a
new
thing,
just
tell
me
to
shut
up,
but
I
I
feel
like
I
feel,
like
you
and
I
are
aligned
here.
Thinking
that,
like
conformance
and
compliance,
are
good,
but
maybe
not
the
same
as
being
able
to
determine
if
an
API
is
versioned
at
a
certain
level
or
if
capabilities
are
in
place.
C
I
think
use
case
wise.
So
one
of
the
things
that
a
lot
of
people
are
looking
at
this
for
right
now
is
image.
Signing
so
I
can
give
you
a
use
case
there,
but
it
could
be
s-bombs.
It
could
be
attaching
cat
pictures
to
every
image
you
push.
It
doesn't
really
matter,
but
something
that
a
user
can
depend
on
either
happening
right,
like
as
an
automated
feature
of
a
service
or
with
a
simple
client
invocation
without
having
to
worry
about
the
underlying
details.
C
I
think
that's
where
capabilities
and
versioning
come
in
right,
I
I
might
have
a
user
that
doesn't
even
know
they're
talking
to
an
oci
registry.
They
don't
even
think
at
that
level.
So
the
idea
of
saying
well,
this
is
an
oci
registry
and
if
I
want
to
know
if
this
is
going
to
work,
I
need
to
assemble
a
certain
type
of
artifact
and
I
will
determine
if
it's
the
right
artifact
by
looking
at
the
oci
compliance
blogs
and
saying.
Okay,
this
one
is
1.1.
C
So
now
I
can
create
an
OCR
artifact
I
might
build
a
tool
where
the
customer
doesn't
even
know
that
there's
an
OC
artifact
being
created,
let
alone.
If
it's
going
to
be
pushed
to
an
oci
register.
It
might
be,
in
other
words,
it
might
be
in
the
context
of
an
entirely
different
product
that
they're,
using
and
ECR
in
our
case
is
like
an
implementation.
Detail
right
or
like
parts
of
azure
Cloud
could
just
be
like
implementation.
Details
of
that,
and
so
I
think
the
idea
of
like
surfacing
the
capabilities
of
the
underlying
implementation
detail.
C
All
the
way
up
to
the
user,
isn't
always
the
best
experience
and
maybe
just
wouldn't
work
now.
It's
absolutely
valid
for
some
client
use.
Cases
like
you,
like
you
have
pointed
out,
but
I,
think
building
those
sorts
of
managed,
Solutions
and
using
sort
of
oci
as
an
implementation
detail.
Is
it
kind
of
Demands
that
we
get
a
little
bit
more
provable
in
our
capabilities.
A
So
let
me
I'm
I'm
trying
to
dig
back
to
actual
implementation
and
scenario
kind
of
stuff,
and
so
let
me
pick
one
out
there
right
now,
which
was
I.
Don't
think
we
have
anybody
from
sex
store
on
here.
So
I'll
just
pick
one
six
door,
because
I
they're
they're
nice
right
now
not
to
pick
a
fight.
I
figured
they're,
the
one
independent
one
in
the
room
because
there's
nobody
here
to
represent
them.
A
Steak
store
right
now
is
best
I
know,
they're,
not
pushing
anything
with
the
new
artifact
manifest.
In
fact
they
held
back
by
pushing
something
with
the
new
content
type
because
Dr
Hub,
wouldn't
they
were
going
to
filter
it
out,
and
so
they
pushed
that
decision
into
their
client
product.
That
said,
hey
there
are
Registries
out
there
that
don't
support
this
stuff,
so
we're
making
the
decision
in
our
tooling
itself
that
we're
not
going
to
push
that
new
feature.
A
Yet
because
we
know
that
if
we
did,
the
user's
gonna
have
a
bad
experience
down
the
road,
and
so
is
that
does
that
make
more
sense
in
terms
of
hey?
That
decision
should
be
pushed
into
the
tooling.
Maybe
there's
a
forward
backward
compatibility
flag
that
you
can
pass
on
the
command
line,
but
it
just
defaults
to
try
and
do
the
most
compatible
thing
and
we're
not
trying
to
push
that
decision
to
be
some
kind
of
automatic
upgrade
in
the
tool.
The
tool
just
knows
that
hey
Registries
out
there.
A
There
are
issues
if
I
try
to
run
into
this,
so
I'm
just
going
to
fall
back
to
the
most
compatible
Behavior
out
there.
But,
but
it's
only
up
by
making
that
decision,
the
one
thing
that
I
really
like
about
that
is
that
that
am
that
content
is
now
portable,
because
I
really
hesitate
the
the
fear
that
I
get
is,
if
we
ever
try
to
make
these
decisions
automatically.
Is
that
we're
going
to
make
decisions
turn
something
into
a
resource?
That's
not
portable.
You
can't
copy
it
around
and
that's
my
that's.
My
big
concern.
C
I'm
going
to
just
reply
to
that,
I
go
all
right,
my
hands
out
no
man's
go
down.
Okay,
I!
Don't
really
follow
that
like
we,
so
so
everything
made
sense
to
me.
There
cosine,
as
the
client
in
Sig
store,
will
do
whatever
it
needs
to
and
that's
kind
of
where
it
started
right.
It
was
like
we
don't
have
a
standard,
so
we're
just
gonna
we're
just
gonna
do
what
we
have
to
do
to
make.
C
C
What
I
don't
understand
is
they
in
in
the
working
implementation?
There
is
something
there
that
isn't
necessarily
portable.
It's
something
that
the
client
needs
to
be
aware
of
to
make
use
of.
Now
it's
portable
in
that
I
can
pull
it
out
of
a
registry
and
push
it
into
another
one,
but
it's
meaningless
without
their
interpretation.
C
A
So
the
portability
what
I'm
getting
at
is
they
are
making
decisions
that
they
want
to
make
sure
this
artifact
they
are
creating,
could
be
push
Docker
hubs.
They
made
decisions
on
configuration,
media
type
where
they're
just
going
to
implied.
They
were
a
regular
image,
even
though
they
weren't,
so
they
made
decisions
on
how
they
did
it
to
push
something
that
was
portable.
That
was
that
could
work
on
any
registry
out
there,
and
so
they
didn't
make
a
runtime
decision
in
this.
They
didn't
query
the
registry
to
see.
Does
this
registry
support
the
different
media
type?
C
Yep
I
mean
I
I,
understand
that
completely
get
that
I
I,
don't
I,
don't
understand
how
adding
sort
of
version
of
versioning
or
capabilities
reporting
from
a
registry
endpoint
can
can
risk
somebody
not
being
able
to
do
that
in
the
future.
But
furthermore,
I
would
think
if
I
would
think
that
if
oci
1.0
included
references
and
artifacts,
they
would
have
just
used
them.
A
A
If
it
was
ubiquitous,
I
think
that's
what
I'm
saying
wouldn't
be
having
this
conversation
yeah.
My
fear
is
this
in
between
time,
where
you're
going
to
have
two
or
three
Registries
that
support
it
and
a
dozen
that
don't
and
if
we
start
making
runtime
decisions
and
saying
hey
I
happen
to
be
pushing
to
a
registry.
It
does
support
today
now
you're
creating
an
object
that
can't
be
copied
to
eight
percent
of
the
Registries
out
there.
C
I'll
Sanjay's
hands
up
I
didn't
realize
I
suck
at
the
hand,
thing
I'm.
Sorry,
you
guys
me.
A
B
I
just
wanted
to
kind
of
like
bring
it
back
to
the
original
discussion
from
a
future
standpoint.
Do
we
want
clients
to
have
those
capable
to
determine
is
what
the
discussion
is:
six
store?
What's
the
forcing
function
for
the
working
group,
so
they
didn't
like
the
solution,
so
there's
clear
indication
that
the
solution
that
existed
was
not
what
they
wanted
right.
So,
given
that
premise
of
why
the
working
group
was
formed,
should
this
group
Define
a
way
to
determine
the
version?
I
think
is
the
primary
question
here.
B
The
in
between
State
I
recognize
is
a
hard
one
right,
but
we
want
to
move
to
the
better
place
where
tags
are
not
the
source
of
binding,
signed,
artifacts
and
s-bombs
and
whatnot.
So
with
that
forward
moving
decision
do
we
want
to
provide
this
capabilities?
What
I
would
like
to
get
this
community
to
focus
on,
for
example,
oci
itself
is
not
majorly
adopted.
B
To
be
honest
right
if
we
say
that
talker
Hub
is
the
majority
of
Chunk
pushing
all
the
art
of
extra
Docker
up
as
a
secondary
solution
like
the
Scorpio
and
Batman
and
different
efforts
that
happen.
So
do
we
want
to
make
sure
that
this
this
new
API
is
complete
in
some
form,
for
the
next
version
of
1.1?
Is
the
primary
question
here?
I
totally
acknowledge
that
the
in-between
solution
is
probably
a
little
confusing,
but
what's
the
forward
direction
is
what
I
would
like
us
to
focus
on
if
possible,.
A
C
A
D
A
Me
thinking
of
the
end
user
scenario:
if,
if
we
create
something,
that's
not
portable
based
off
of
what
the
red
tree
does
now,
we
create
upgrade
issues,
say
I'm,
creating
a
CI
CD
pipeline
I've
push
to
an
internal
registry
in
the
company,
and
then
that
gets
copied
out
to
an
external
publicly
facing
registry
later
on.
If
I
test
my
upgrade
on
the
internal
registry,
first
I
just
work.
My
whole
CI
CD
pipeline,
because
now
all
the
objects
I
create
can't
be
pushed
out
to
the
production
server.
A
B
A
D
C
Go
for
it
I
think
yeah
I
mean
I,
think
this
gets,
but
no,
we
I
think
we
all
want
portability
so
that
I
will
not
argue
with
that.
Like
yes,
there's
there's
a
goal
of
portability,
there's
I
think
where
I'm
getting
hung
up
here
is
functionally.
C
We
can
have
code
that
needs
to
know
if
it
can
create
an
artifact
and
push
it,
and
if
there's
a
refers
API
right,
so
we
can
ping
for
the
refers
API
and
if
it's
there
or
not,
we
know
and
we
check
a
box
and
then
we
can
assemble
an
artifact
and
push
it,
and
if
it
fails
with
a
particular
error
code,
we
know
that
it's
not
supported,
and
if
it
succeeds,
then
we
don't
support
it.
Now
we
check
that
box.
C
You
know
in
in
the
client
from
there
I
think
all
I
would
like
to
see
is
for
us
to
have
an
ability
to
either
check
an
API
version
or
to
retrieve
a
capabilities
blob
to
tell
me
that
those
things
are
there
or
not,
and
then
I
can
Implement
that
a
little
cleaner,
without
ideally
without
any
user
interaction
and
hey,
Jason
and
and
I
guess
like
a
follow-on
to
that
is
portability
wise
and
I.
C
That
would
change
that
right,
like
if,
for
example,
you
know
the
foo
registry
out
there
in
the
world
which
doesn't
exist,
I
hope
is
1.0
forever
because
they
just
want
to
be
there
and
I
create
an
artifact
in
an
ECR
and
I
pull
it
with
scopio
and
I
want
to
push
it
over
there
it'll
fail
that's
the
way
it
is
right,
I
mean
they
don't
yet
support
1.1,
so
I'm
I'm
not
sure
how
that's
I
wouldn't
categorize
that
as
non-portable
I
guess,
that
was
the
thing
I
was
hung
up
on
before
too.
D
And
can
I
I
would
also
say
like
it
is
still
portable,
but
what's
important
is
is
like
what
it
right
wraps:
it's
not
the
Manifest
itself,
and
so,
if
you
have
a
signature,
that's
wrapped
in
an
artifact
manifest
and
pushed
to
a
registry
that
supports
artifacts,
and
you
want
to
copy
that
to
a
registry
that
has
not
yet
supported
the
new
artifact
manifest
you
can
convert
that
and
yes,
it
changes
the
digest,
but
the
important
parts
of
it.
What
is
already
you
know,
cryptographically
sound,
can
be
ported
between
registries
and
and
work
with.
A
I
feel,
like
all
other
plays
tearing
on
me
on
that
one,
because
I
just
keep
going
back
to
the
the
same
scenario,
for
me,
is
the
the
tooling
at
runtime.
If
you're,
creating
something
you're
changing
what
you're
doing,
you
can
only
make
that
decision
based
off
the
one
register
you're
talking
to,
and
you
don't
have
the
visibility.
The
user
has
that's
running
your
tool.
A
That
knows
where
that
resource
might
be
pushed
to
later
on
inside
I
just
end
up
pushing
it
back
to
that
for
anything
I'm
right
now,
pushing
back
to
the
user
itself
is
generating
it
rather
than
trying
to
have
the
tool.
Do
a
runtime
decision
that
that's
where
I
keep
saying.
Let's
give
me
a
use
case
that
doesn't
involve
something
like
that.
Give
me
a
use
case
where
you
know
it
actually
does
need
to
be
happening
at
the
tool
and
not
the
user
level.
A
A
B
Has
a
this
should
have
a
disclaimer,
the
user
should
know
where
the
content
goes.
Otherwise,
you
have
redistribution
issues
and
all
that
stuff,
so
I
think
it's
fair
to
assume
that.
Yes,
the
user
produces
an
artifact
and
they
know
the
targets
where
the
content
is
going
is
a
fair
statement,
but
either
way
I
would
like
people
to
maybe
comment
on
the
issue,
because
there's
no
indication
of
who
wants
that
issue
supported
or
not
and
what's
the
path
forward
is,
is
still
not
clear
like
should
we
make
a
proposal?
B
Should
we
not
Implement
that
API
or
that's
still
not
coming
out
from
that
issue
just
from
a
process
standpoint,
it's
still
a
little
gray,
Jason.
E
You're
at
the
risk
of
just
disagreeing
with
everything
everyone
says
your
your
example
of
the
artifact
producer
should
know
where
it's
going
to
end
up
getting
published
to
I
can
imagine.
E
Somebody
like
Prometheus,
builds
a
Prometheus
image
and
distributes
it
via
yaml
or
a
Helm
chart,
or
something
with
the
idea
that
it
is
supposed
to
be
sort
of
pulled
into
your
registry
when
you
install
it
and
pulled
into
whatever
other
registry
when
you
install
it
over
here
and
that's
that's
sort
of
they
they
some
some
projects
do
this
today,
where,
like
they
produce
something
somewhere
in
one
registry,
but
then
the
installation
process
actually
puts
it
into
your
registry
and
that's
outside
of
there.
E
You
know
control
right
now
we
only
have
one
like
there
is.
No.
There
is
very
minimal
compatibility
worries
so
that
when
Prometheus
does
that
they
don't
have
to
worry
about
every
registry
supporting
it
but
like
if
we're
going
to
introduce
one
of
those
I
wouldn't
want
to
put
it
back
onto
Prometheus
and
every
project
to
distribute
a
oci
1.0
version
of
their
artifacts
and
oci
1.1
version
of
their
artifacts
and
make
users
care
about.
All
of
that
does
that
does
that
example,
make
any
sense
am
I
just
completely
crazy.
C
C
A
I
had
to
take
my
hand
down
because
you're
like
if
anybody
disagrees,
raise
your
hand
and
I
was
like
crap
my
hands
up
yeah
from
from
my
standpoint.
A
Thinking
along
the
lines
of
if
I
was
building
a
Helm
chart,
I
keep
saying
end
user,
an
end
user
might
not
be
whoever
random
person
is,
is
trying
to
run
their
application.
It's
probably
someone.
That's
making
the
tooling
that
user
is
using
to
build
their
stuff
and
so
that,
if
your
tooling
is
say,
I
want
to
build
a
Helm
chart.
A
The
tooling
out
there
might
make
the
decision
for
the
user
that
we're
going
to
make
these
Helm
charts
in
a
way
that's
very
compatible
to
go
across
a
lot
of
places,
because
we
don't
want
users
to
report
back
they're,
having
issues
building
and
pushing
home
charts
to
their
registry.
And
so
it's
it's
a
question
of
portability.
For
them
they
want
to
make
sure
they
stay
in
a
very
portable
state
for
a
longer
period
of
time
until
they
feel
comfortable
making
that
switch
in
the
tooling.
E
Yeah
Tiana's
example
in
the
chat
is
also
good.
That
gzip
and
and
Z
standard
compression
is
a
similar
thing.
I
think
that's
a
good
analog.
E
I
I
missed
the
first
half
hour
of
this
and
I
apologize.
If
what
I'm
about
to
say
has
already
been
beaten
to
death,
but
for
what
it's
worth,
I
I
agree
with.
Brandon
I
will
put
it
in
the
the
issue
as
well
on
the
record,
but
I
I
agree
with
Brandon.
That
I
think
it's
better
to
have
capability
checking
be
done
via
an
actual
call
to
the
actual
API,
rather
than
have
a
capability
endpoint.
E
A
You're
also
kind
of
got
like
this
is
always
yeah
two
area
handlers
for
the
exact
same
error,
depending
on
how
they
get
to
that
path.
What
I'll
say
that
we
kind
of
went
into
so
maybe
taking?
What
Jesse
is
about
to
say
here
was
that
works
code
for
an
API?
It
doesn't
work
if
you're
trying
to
figure
out
a
supportive,
manifest
type
and
so
they're.
A
The
question
that
has
been
raised
is:
do
they
want
to
have
the
ability
for
tooling
to
automatically
upgrade
to
a
different,
manifest
type
from
pushing
an
image
spec
artifact,
to
pushing
art
to
push
an
artifact
manifest
directly
based
off
of
whatever
their
registry
currently
supports?
Now
is
where,
throughout
the
scenario
that
what
one
registry
supports
might
not
be
what
the
other
registry
support
that
you're
going
to
push
this
to
later
on.
That
was
my
fear,
and
so
we
went
back
and
forth
on
that.
A
little
bit,
I.
C
Totally
agree
with
that,
the
only
caveat
is
I
trust.
Versioning
I
mean
it
like.
If,
if
a
registry
says
it's
1.0,
then
it's
I'm
not
going
to
assume
that
it
supports
OC
artifacts
and
if
it
says
it's
1.1
I'm,
going
to
assume
that
it
does
support
oci
artifacts
and
then
my
code
will
be
defensive
enough
to
know
that
it
might
still
fail
and
I
have
to
ever
handle
it.
That's
fine,
but
but
that's
the
problem.
C
It's
not
whether
or
not
an
API
exists
which
I
also
have
a
problem
with,
but
that's
just
because
I'm,
an
old
OS,
graybeard
and
I
think
everything
should
be
versioned.
Whatever
I
like
to
wrap
things
right,
if
I
wrap
an
SDK
around
this
thing
can
I
abstract
it
from
a
user.
What
you're
saying
is
no.
The
user
has
to
be
somewhat
aware
of
what
my
underlying
implementation
is.
I,
don't
love
that.
A
So
they
need
to
be
aware
and
again
the
user
might
not
be
end
user
building
the
helm
chart
that's
going
to
be
potentially
the
user
writing
the
software
that
builds
home
charts
or
the
packages
Helm
charts.
You
know
it's,
not
the
person
running
their
individual
home
chart
so
whoever's
making.
That
decision
is
going
to
be
looking
at
it
from
a
high
level
of
saying.
Look
70
of
registry
support
this
30.
A
We
still
have
that
workflow
so
depending
on
which
these
two
conversations
we're
having
I
think
we've
got
the
fall
back
as
you're.
Looking
at
supported
apis
on
the
registry,
but
we
don't
have
the
automatic
fallback
for
the
media
type
itself.
Just
because
you
know
the
the
concern
for
me
is
that
you
just
don't
know
where
that's
going
to
get
moved
to
later
on.
E
A
B
A
Now,
outside
of
this
I
think
if
you
pass
the
conformance
test
for
1.1,
you're
gonna
have
both
but
that's
outside,
of
whatever
we're
looking
at
right
here.
So
there's
still
a
carrot
at
the
end
of
this
I,
don't
want
to
say,
there's
a
stick:
we'll
only
use
carrots
for
our
stuff
that
Registries
are
going
to
want
to
support
both
but
timing,
wise
I,
don't
think
we
have
control
of
saying
a
registry
is
going
to
implement
this
feature
before
the
other
feature.
C
C
E
C
No,
that
is
not
at
all
yeah.
No,
like
we
support,
we
support.
Image,
manifests
hey
how
you
doing
we're
not
oci
compliant
I.
Don't.
C
I
have
some
issues
with
the
HTTP
codes.
No,
no,
there's
there's
a
couple
of
things
that
are
completely
unrelated
to
the
mainstream
way
that,
with
most
of
our
users,
use
the
registry
that
you
know
and
make
us
not
not
check
the
box
on
compliance.
We
will
fully
support
this
in
a
compliant
manner.
That's
my
point
is
that
we
can't
say:
oh
does
that
thing
I
mean
effectively.
Docker,
Hub
and
ECR
are
just
not
registers.
You
can
never
use
because
neither
of
them
are
compliant
right.
That's
not
a
thing
right.
C
E
C
E
Right
yeah:
what
is
everyone's
answer
to
that
on
three.
E
C
So
what
I'm
hearing
from
this
is
that
we
don't
actually
have
a
decision,
but
it
feels
like
the
opinion
and
I
know
we're
going
over
now.
It
feels
like
the
opinion
is
such
that
tool
like
clients,
client
software
should
should
basically
poke
at
things,
and
if
they
don't
fail,
then
they
can
move
on
and
use
them
and
that
we're
we're
not
thinking
that
either
you
know
version
string
on
an
API,
endpoint
or
or
capabilities.
Api
endpoint
is
something
that
we
want
to
pursue.
A
Or
apis
yes
for
media
types,
I
think
I'm
still
holding
back
and
saying.
Let's
try
to
push
that
into
more
of
a
hard
code
in
the
tooling
and
put
Flags
near
to
avoid
using
features
before
people
are
ready
for
it
state.
But
I
am
willing
to
entertain
that
we
might
need
a
capabilities
API.
If
we
can
find
a
good
use
case
there,
I
just
I,
don't
have
it
yet
I'm
still
looking
for
what
that
use
case
is.
B
Brandon
I
support
you
for
making
sure
that
tooling
needs
to
flag
because
yeah
I
don't
want
our
honestly
I'm,
not
a
supporter
of
automatic
conversion,
but
I
want
to
fail
fast.
Today,
I
can't
fail
fast
in
the
tooling,
even
to
kind
of
like
quickly
determine
without
making
a
call
to
reference
checking
sub
status,
pushing
the
oci
Manifest
there's
a
bunch
of
places
where
we
need
to
do
this,
and
people
have
written
this
code.
Are
the
people
who
actually
said
like
we
cannot
fail
fast,
cannot
deterministically
fail
fast.
Also
because
refers
can
be
behind
authentication.
B
So
you
want
to
get
200
back
right.
That's
what
we
said,
but
now
the
oci
Manifest
might
or
might
not
get
supported,
because
it's
in
a
different
specification,
so
just
making
sure
that
we
can
fail
fast.
Okay,
let's
take
your
example
of
client
is
saying:
I
want
to
put
a
new,
manifest
type
that
they're
forcing
it.
That's
the
that's
the
model
that
they're
choosing
the
client
cannot
determine
strictly
even
go
through
that
flow,
because
the
Manifest
put
might
succeed
and
reference
might
fail
or
the
reference
will
succeed
and
the
Manifest
put
might
fail.
B
B
Don't
do
this
right
or
the
referrals
will
return
a
sub
status
that
says:
okay,
my
repository
doesn't
exist,
but
I
do
support
the
referencing
or
something
like
that
that
portion
of
the
spec
is
a
little
gray.
So
it's
not
about
conversion
that
I'm
going
after
I'm,
clearly
going
after.
Let's
fail
fast
and
the
spec
should
allow
us
to
fail
fast.
A
That's
probably
the
best
best
explanation
or
scenario
that
I
could
think
of
that
I've
heard
so
far,
so
that
one
I
can
buy
and
I
would
say
the
rephrasing
it
for
her
right
is
before
you
start
pushing
blobs
before
you
start
doing
authentication
you
want
to
know
if
you
can
even
push
this
object
to
the
registry
before
doing
that
stuff
and
so
right.
B
Because
clients
are
going
to
create
this
manifest
on
disk
right
so
now
what's
happening.
Is
that
you're
creating
this
new
stuff?
Because
you've
said
you
want
all
this
you've
done,
the
workflow
you
put
the
signature
done
the
Json
log,
the
Json
there's
a
bunch
of
logging
that
happens
under
the
covers
and
then
you're
like
trying
to
push
in
like
boom.
B
It
just
failed,
so
I
think
just
being
able
to
fail
fast,
saying
that
okay,
this
registry
doesn't
support
is,
is
still
is
the
value
add
here,
I,
don't
I
think
we
kind
of
lost
the
discussion
of
whether
we
want
to
get
both
these
API
or
not.
But
just
focusing
on
the
use
case
of
how
can
we
deterministically
say
that
this
new
stuff
is
not
supported?
Is
they
ask
here.
C
B
A
E
Is
there
anything
else
we
wanted
to
discuss
I'm
also
happy
to
leave
earlier?
If
there's
nothing
else
on
the
docket.
A
I'm
sure
there's
stuff
I'm
forgetting
about
but
I
can't
think
of
it
right
now.
I
know:
I
got
a
lot
of
stuff
to
sit
in
the
queue
we
do
have
the
election
going
on
now,
so
anybody's
maintaining
stuff
make
sure
you
vote.