►
From YouTube: OCI Weekly Discussion - 2023-05-04
C
B
Yeah
I
think
the
the
Highlight
for
you
to
read
is
on
the
considerations.
I
added
a
couple
examples
of
types
of
the
implementations
make
it
a
little
clearer,
I,
think
and
then
I
also
relaxed
on
line
seven
of
considerations.
The
must
not
to
a
should
not
okay,
because
I
think
third-party
implementations,
runtimes
and
whatnot
might
want
to
generate
errors
on
unknown
properties,
and
it's
not
our
sort
of
place
to
decide
their
compatibility.
Promise.
D
A
A
A
A
A
E
A
Yeah,
okay,
just
through
the
issue
out
there
today,
someone
opened
an
issue
up
on
my
own
code
and
I
was
looking
at
saying.
Well,
why
am
I
not
Parsons
thing
that
looked
I
was
like
oh
so
I'm
looking
through
and
saw
that
you
were
actually
parsing
it
with
the
mime
type
stuff
and
go
and
I'm
like
that's
pretty
good
with
some
other
people,
and
other
people
are
not
thinking.
Okay,
this
is
gonna.
E
A
A
So
I
I'll
drop
that
out
there
to
say
which
way
do
we
want
to
go
and
then
once
we
figure
out
what
we
want
to
do
we'll
go
ahead
and
open
up
a
PR,
so
it
might
be
a
light
group
today
I'll
go
ahead
and
do
a
screen
share
that
way.
We
can
be
on
the
same
page
of
this
stuff.
First
I'm
going
to
type
my
name
in
because
if
I
don't
do
that,
I
promote
sure
and
I'm
just
worse
and
new
keyboard
today
or
relatively
new
to
me,.
C
A
A
A
A
So
yeah,
let's
see
here's
the
first
on
the
list
here.
1050,
which
is
just
saying,
hey,
send
first
stuff
we're
doing
it
wrong.
So
I
know
we
were
back
and
forth
in
the
chat,
but
I
just
wanted
to
bring
this
one
up.
Saying
hey.
We
should
probably
change
word
one
here
and
it's
a
one
character.
Change
minus
to
a
plus
I
figured
those
the
easiest
kind
of
changes
all
as
in
documentation.
It's
not
even
in
code.
A
A
A
I
think
the
reason
not
to
follow
Dash
Dev,
which
is
what
we're
currently
doing,
is
that
it
sorts
it
wrong.
Aquarius,
Ember,
plus
Dev,
is
a
little
less
common
I've
seen
that
to
show
up
as
equal.
What
were
you
saying
right
there?
If
you
say
whatever
Plus
debit
shows
up,
as
you
know,
equivalent,
but
that's
less
incorrect
than
what
we're
doing
now,
which
is
my
estab,
which
implies
that
it
is
before
the
1.0
release
and
we're
saying
this
is
minus
1.1.
rc3.
A
E
I,
remember
I,
don't
know,
I
mean
in
the
tag
tag,
overloaded
tag
per
se
like
the
distribution
tag,
so
in
Helm,
when
we,
when
we
had
this
discussion,
how
Muses
plus
us
very
very
explicitly
all
over
the
place,
and
so
when
we
try
to
convert
the
helm,
Sim
War
to
like
a
like
a
repo
tag,
equal
and
it
blew
up
all
over
the
place
and
we
needed
some
canonicalization
magic.
It
doesn't
matter
that
we
go
down
that
route
or
should
we
just
not
worry
about
the
two
together.
A
C
A
B
E
A
F
A
B
Yeah
I
think
this
just
brings
the
pr
in
line
with
your
comments
and
clarifies
the
distinction
between
application,
implementations
that
are
storing
and
copying
content
versus
implications
that
are
processing
and
I've
clarified
as
well.
You
know,
registry
distribution,
spec
implementations
are
the
former
runtime
runtime
spec
implementations
are
the
latter
and
that
the
latter
has
slightly
different
sort
of
constraints
than
the
former,
and
we
don't
want
proxies,
for
example,
to
modify
media
types
when
they
they
receive
a
media
type.
B
And
the
line
45
right
next
to
your
cursor,
it's
sort
of
a
safeguard
regarding
some
of
the
intentions
I
raised
around
999.
Is
we
started
having
non-json,
for
example,
media
types
in
the
config
field?
They
might
reference
things
that
aren't
really
valid.
Parse
objects
for
a
given
implementation,
and
so
if
an
inflation
finds
an
unexpected
media
type,
it
should
not
try
to
run
it
through.
You
know,
potentially
memory
unsafe,
parser
or
anything
like
that.
Just
treat
it
as
an
opaque
blob.
If
you
don't
understand
what
this
thing
is.
A
B
Think
there
might
be
some
language.
That's
actually
an
interesting
point
around
not
rejecting
unknown
artifact
types
that
maybe
I
need
to
add
back
in
I
had
to
rebase
this
PR
on
top
of
yours,
so
I
might
have
to
go
back
and
and
check
to
see
if
I've
flagged
that,
because
I
think
you're
right
for
config
media
type,
I'm,
definitely,
okay,
with
maintaining
sort
of
the
the
current
sort
of
oci
1.0
restrictions
and
just
like
encouraging
invitations
not
to
parse
unknown
contact.
We
could
definitely
relax
that
45.
A
A
A
B
A
A
lot
of
this
was
written
with
the
assumption
that
we've
got
Registries
and
runtimes,
and
we
didn't
think
that
there
were
going
to
be
anything
else
showing
up.
So
this
was
written
before
we
got
to
this
kind
of
chaos,
and
it
might
mean
that
there
needs
to
be
some
more
tuning
to
take
it
to
take
into
consideration
all
those
other
users.
B
A
I
get
the
feeling
that
the
whole
point
of
47
and
49
there
is.
The
list
was
probably
geared
more
toward
run
times
of
saying
anybody.
There's
no
CI
runtime
needs
to
support
at
least
this
one
config
and
leaving
it
open
in
the
future
that
someone
could
have
some
kind
of
lesson,
specific
config
or
something
some
other
kind
of
runtime.
B
I
do
know
that
some
implementations
are
going
to
go
down
the
path
of
having
possibly
both
an
artifact
type
and
their
own
config
descriptor.
So
perhaps
The
Language
online
34
could
just
be
copied
down
into
the
config
media
type
as
well.
Is
that
if
you're
just
involved
in
storing
and
copying
image
manifests
that
you
should
accept
Singularity
configs
as
well
as
Helm,
configs
and
others.
A
E
B
I
guess
we're
operating
in
the
sort
of
gray
area
where
we'll
say
that
we're
concerned
about
something
that
Registries
might
not
accept.
Is
there
a
feedback
mechanism
I
mean
sort
of
what
one
more
aggressive
action
would
be.
You
know,
take
the
make
these
changes,
merge
them
and
then
wait
for
feedback,
but
is
there
another
feedback
mechanism,
that's
sort
of
a
softer
touch
to
say
how
do
you
feel
about
this
language
or
how
can
we
resolve
impasses
when
we're
worried
about
something
that
might
be
in
the
hypothetical.
E
Are
we
crossing
the
boundary
that
every
registry
should
accept
everything
in
the
sense
that
is
there
a
possibility
that
certain
media
type,
aversions
or
certain
kinds
of
artifact
types
are
going
to
be
proprietary
and
not
something
that
certain
providers
want
to
accept?
Do
we
have
provisions
of
that
in
here?
The
moment
we
say
it
shouldn't?
It
must
accept
everything.
E
Then
we
kind
of
cross
over
this
as
and
non-compliant
implementation
and
there's
no
opportunity
for
operators
to
decide
what
they
can
store
or
what
they
can't
store
like,
like
I,
said
yeah
I'm,
I'm,
leaning
towards
it's,
it's
possibly
better
to
make
sure
that
everything
can
be
stored.
But
it
also
warrants
like
say,
for
example:
Singularity.
Is
that
a
type
that
every
operator
wants
to
store
right.
B
So
I
think
I've
tried
to
be
very
careful
and
say
it
unknown,
media
types.
So
if
a
operator
chooses
to
reject
Singularity
or
a
proprietary
media
type,
for
example,
they
that
is
known-
and
so
they
can
load
or
Implement
that
exception.
But
the
idea
is
in
order
to
make
registry
oci
1.1
a
meaningful
Baseline
for
the
applications
regarding
artifacts,
both
for
Helm
and
Singularity,
but
also
as
bombs
and
the
stations
and
the
like
is.
E
E
D
A
B
G
G
A
B
G
B
G
Yeah
I
think
our
concern
has
always
been
about.
You
know,
fields
that
have
no
no
limits
or
restrictions
or
unknown
Fields
entirely
right,
like
an
artifact
type,
has
to
we
can.
We
can
put
it
through
a
regex
and
we
can
make
sure
it's
a
media
type
and
it
can
be
a
certain
max
length
and-
and
so
at
that
point
it's
easy
to
say,
yeah.
Let's
accept
anything
that
matches
that.
A
A
Yeah
and
I
certainly
get
where
you're
trying
to
go
with
that
when
I'm
I
was
putting
it
out
there
of.
If
you
want
this
approved
quick,
then,
as
is
right
now,
it
was
probably
easier.
If
you
want
this
approved
with
that
change
and
solving
the
hard
problem,
then
you
know
take
a
little
bit
of
time
to
solve
the
art
problem
and
we're
notorious
for
everything.
Taking
a
long
time.
A
B
B
And
only
on
only
imposing
the
requirement
on
drawing
and
copying
implementations,
and
then
it
sounds
like
we
might
want
to,
and
this
one
I
think
maybe
should
be
just
pulled
out
into
a
separate
PR.
Is
this
language
is
very
specific,
as
you
said,
to
run
times
and
I'm,
not
sure
how
we
want
to
handle
that.
B
I
can
just
add
this
line
then,
and
I
commit
and
I
think
we'll
need
to
think
about
this.
But
maybe
it's
not
an
issue
for
now
is
if
it's
an
unknown
media
type,
then
it's
unknown
and
it
will
would
be
accepted.
I
guess
under
the
rules
is
written
and
it
would
just
be
the
hypothetical
of
a
registry
that
only
accepts
Helm,
charts.
I
guess
would
violate
the
rule
because
it
would
not
accept
image.
C
A
A
F
E
B
E
A
A
A
A
A
A
And
the
reason
I'm
willing
to
go
with
that
is
I
suspect.
What's
happening,
is
dock
or
does
their
upload
as
a
single
chunk,
they
say
give
me
a
chunk
upload,
push
a
single
chunk
and
then
send
the
digest
to
the
end
of
the
follow-up
request,
and
so
my
assumption
there
is
that
in
that
one,
big
single
chunk
that
they're
just
sending
everything
streaming
it
the
compression
of
the
layer
and
whatnot
on
the
Fly,
and
so
they
don't
know
the
length
in
advance.
A
E
A
A
This
is
one
that
IBM
Mike
Brown.
You
and
I
have
going
back
and
forth
on
this
one
a
couple
times
which
is
when
we're
talking
about
registry
versus
repository,
the
terminology
in
there
I
think
there's
been
a
lot
of
back
and
forth
of
saying
one.
That
was
just
too
long
for
me.
Sorry,
Mike,
that's
just
too
long.
I
can't
do
it,
but
overall
in
here
I
think,
there's
a
back
and
forth
of
whether
or
not
the
specs
should
say
that
a
lot
of
this
stuff
is
in
a
specific.
A
A
If
you
try
to
do
an
upload
and
your
blob
was
in
a
different
repository,
it's
just
going
to
say
that's
not
going
to
blob
to
your
repository,
and
so
a
lot
of
these
apis
are
scoped
to
an
individual
repository
for
all
the
different
blobs
within
a
manifest,
and
some
I
was
trying
to
clarify
that
in
here
and
I
think
what
I
ran
into
is
people
saying?
Well,
you
can't
necessarily
say
that,
and
yet
we
get
users
coming
to
us.
Saying
hey
I
tried
to
do
a
lot
of
stuff
on
the
Spectrum.
A
A
It's
been
so
long
style
for
this
one,
but
the
reasons
came
up
was
there
was
a
question
on
garbage
collection
to
which
I
was
trying
to
be
good
of
saying
we
don't
touch
garbage
collection
and
at
some
point
in
their
there
was
a
question
of
whether
or
not
things
are
allowed
to
go
across
and
so
I
was
yeah
references
or
specific
repository
I.
Don't
think
we
say
that
references,
our
specific
repository
in
our
spec
right
now.
A
C
A
A
A
D
D
D
A
D
A
Correct,
but
in
this
case
we're
saying,
if
I'm
trying
to
do
a
manifest
pull
and
is
not
found
in
the
X,
the
response
is
404.
That's
what
we're
looking
at
here.
So,
if
I'm
doing
a
pull
of
a
manifest
and
the
pull
itself
is
scope,
the
poll
says:
I
am
pulling
from
this
URL
this
whole
path
here
and
there
is
V2
slash
whatever
repository
in
there.
D
C
A
D
E
A
E
I
think
scoping
is
the
problem
there.
Honestly,
getting
rid
of
in
the
registry
would
clarify
it
because
you're
within
context
of
that
call,
whether
it's
I
mean
cross
Mount
is
another
problem
right.
It's
not
within
the
repository.
It's
a
cross
repositories,
so
I
would
say
getting
rid
of
the
in-registry.
The
problem
is
that
we
have
a
three-part
definition
here,
which
is
registry
repository
and
the
last
portion,
which
is
name
tag
or
reference,
or
something
like
that.
So
we
haven't
defined
that
in
the
specification,
but
we
use
a
reference
everywhere,
I
think
in
the
registry.
A
D
A
A
I
I
think
I
drugged
that
issue
out
as
long
as
I
could
was
that
the
last
one
I
listed
are.
We
did
I
have
garbage
question
in
there.
No,
that
was
the
last
one
right
on
time:
holy
cow,
all
right,
I,
don't
think
you
made
any
progress.
We
made
a
little
bit
of
progress,
but
I
still
think
it
was
good
me.
So
thank
you.
Everybody
for
showing
up
and
for
everybody's,
going
to
be
in
the
open
source
Summit
next
week.
Look
forward
to
seeing
you
there
for
anybody.