►
From YouTube: OCI Weekly Discussion - 2022-03-31
B
And
the
actual
item
recordings
for
the
reference
type
working
group
they're
wondering
oh,
who
uploads
theirs?
That's
me
I
I
figure,
that's
why
you
didn't
want
to
meet
today.
A
B
Be
funny
it
remembers
the
last
time
you
were
there
and
didn't
update
for
a
second
okay
yeah,
but
I
was
saying
all
kinds
of
bad
stuff
about
josh
this
weekend,
so
he
wanted
to
see
the
replay,
so
he
could
figure
out
everything
I
said
about
him.
A
B
A
B
So
yeah
other
than
that,
and
I
do
want
to
kind
of
slow
walk
this
case
people
are
still
joining
in.
I
only
had
two
little
issues
on
there
well
one
little
issue
of
my
own
and
then
the
other
one
kind
of
popped
in
there.
I
thought
maybe
maybe
worth
a
little
chat
about
that
wasn't
mine,
but
I
put
my
name
by
it
anyway.
B
B
You
know
we
say
it's
all
that
good
stuff
and
that
yeah
they
must
ignore
unknown
properties,
and
then
I
just
had
an
extra
line.
There
just
said:
hey:
if
you're,
storing
a
returning
manifest
in
a
content,
addressable
store,
you
shall
not
modify
the
content.
B
There
may
be
better
ways
to
say
it.
There
may
be
other
things
we
want
to
say
in
here,
but
I
figured
at
least
get
a
starting
point
there
and
get
the
conversation
going.
D
B
B
B
Say
that
state
again
and
and
this
might
be
for
the
distribution
but
yeah
yeah,
I'm
thinking
of
like
aws,
when
they
they
did
some
of
their
filtering
other
people
might
be
doing
that
too.
In
distribution
spec,
we
document
all
the
different
return
codes.
If
you
do
x,
y
or
z,
I
don't
think
we
have
anything
in
there.
That
says
hey
if
you're
filtering
on
these
things
for
unknown
content
in
there.
A
B
I
was
saying:
do
we
want
to
just
specify
this
one
change
over
here,
which
is
to
our
accessibility
clause
so
we're
in
here
at
the
top,
and
we
say
you
know
for
anybody
reading
and
processing.
They
must
not
generate
an
error
if
they
encounter
something
that's
unknown
and
for
implementations
that
are
storing
returning
since
it's
a
content,
addressable
store,
they
shall
not
modify
the
content,
that's
kind
of
one
line
we
just
added
in
there.
B
What
I'm
wondering
from
the
aws
had.
This
doesn't
make
sense
to
document
if,
for
some
reason,
our
registry
wants
to
reject
some
content.
For
any
reason,
we've
we've
seen
this
from
even
like
docker
hub
says:
hey.
We
want
filter
on
media
type,
so
it's
not
just
aws,
but
I
don't
think
we
have
a
docker
hub
representative
over
here.
Do
we
want
to
document
on
push
what
the
return
code
is?
You
know
right
now,
we've
got
like
a
push,
his
manifest
blob
unknown,
but
you
know
it
may
reject
it.
E
So
I'm
I'm
going
to
speak
on
behalf
of
myself,
not
on
behalf
of
behalf
of
ecr,
because
I'm
not
you
know
on
there.
I
think
that
it
is
reasonable
in
a
specification
to
say
that
there
are
errors
that
can
be
returned
in
certain
situations
and
then
to
define
what
those
errors
might
be.
That,
of
course,
might
be
different
than
the
current
behavior
of
ecr.
E
If
you're
introducing
an
error
code
that
ecr
is
not
returning
today.
So
I
know
that
ecr
is
not
fully
compliant
in
terms
of
its
return
codes
with
everything
today
or
in
terms
of
its
behavior
with
respect
to
unknown
properties,
because
vcr
does
not
allow
unknown
properties
and
documenting
a
different
return
code.
Would
then,
you
know,
force
us
to
go
and
change
that
if
we
want
to
be
compliant
as
well.
E
B
B
Don't
worry,
sam,
so
other
than
that
questions
concerns
on
this
one
I
mentioned
this
was
a
quick
one,
so
I
don't
think
there's
probably
a
lot
of
conversation
on
this
part.
It
might
just
be
more.
Do
we
want
to
add
something?
A
distribution
spec
on
the
other
half.
D
Yeah,
sorry
so
for
huey
for
quite
a
I
o,
specifically
for
unknown
blobs,
we
don't
have
404..
I
don't
know
if
that's
according
to
spec
but
again
like
the
spec,
doesn't
tell
which
specific
error
to
return.
B
Is
that
for
a
blob,
that's
not
found
or
for
a
blob
that
doesn't
conform
to
your
filtering
requirements?
Oh.
B
Yeah,
I
think
if
it's
unknown,
that's
one
the
one
I'm
looking
for.
I
have
to
dig
through
this.
A
little
bit
farther
say
push
manifest.
D
Yeah
we
have
a
white
list
of
acceptable
blog
like
manifest
types
that
we
allow
and
anything
else
on
unknown
blog,
which
right
now
is
a
404.
B
B
All
right,
so
I
might
just
open
up
an
issue
on
the
side
and
get
some
more
conversation
going
on
github
before
trying
to
actually
push
a
change
and
going
out
and
looking
at
what
other
registries
are
doing
right
now.
Just
get
a
good
idea,
four
or
four
might
be
good
enough.
B
Okay,
so
that
was
the
quick
one.
This
one
might
be
a
bit
more.
They
wanted
to
deprecate
oci
which,
as
soon
as
I
see
those
two
words
in
the
same
sentence,
I
get
panicky
and
really
what
they
want
to
do
is
document,
let's
see
if
they
put
in
the
content
over
here,
they're
doing
a
couple
of
annotations
that
you
want
to
add.
B
They
want
to
add
image,
support,
end
of
support
and
they
want
to
add
image,
support
info,
and
I
think
that's
it
after
some
comments
out
there,
I'm
not
a
maintainer.
So
it's
just
me
thinking
out
loud,
but
the
idea
here
was:
they
want
to
be
able
to
communicate
to
end
users
that
hey
this
ubuntu
image
that
we
released
four
years
ago
in
supported
shouldn't
be
used.
B
It's
deprecated
and
they're,
hoping
that
runtimes
can
even
spit
that
out
to
the
end
users,
when
they
try
to
pull
out
an
old,
unsupported
version
of
the
image
that
they
get
some
errors
coming
back.
That
just
says:
hey
this.
This
is
not
valid.
You
should
not
be
using
it
anymore
with
the
goal
that
hopefully,
users
start
updating
their
base
images
they're
using
for
things
and
stop
running
old,
deprecated,
unpatched
talent,
support,
stuff.
A
B
B
They
had
an
extra
one
in
here
like
make
sure
I'm
quoting
them
right,
because
they
had
another
section
in
here
where
they
said
it
should
output.
One
of
these-
and
I
think
it
was
the
support
info
yeah-
should
be
displayed
by
anything
with
deprecation
status,
so
they're
hoping
that
if
it
gets
deprecated,
this
field
gets
displayed
to
the
end
user,
so
that
was
their
workflow
they're.
Looking
at.
C
B
Yeah,
it's
non-trivial
there.
It
might
be.
You
know
some
of
the
tooling
I've
I've
been
playing
with
on
the
side
has
been
to
make
changes,
mutate
an
image
and
that
changes
the
digest
course,
but
for
an
annotation,
that's
a
really
minimal
change.
So
you
could
potentially
say
we're
supporting
this
for
the
next
six
months.
Then
come
back
three
months
later
and
say
we're
going
to
support
this
for
another
six
months.
Just
keep
pushing
that
out.
B
C
A
No,
I
mean
like
this
is
one
of
those
things
to
be
amazing
if
somebody
knew
this
up
front,
but
I
I
guarantee
you
as
soon
as
you
put
a
support
info
curl
in
here
and
it's
like
five
years
out
and
then
the
url
has
changed
in
that
five
times
five
years
time
and
they'll
ask
for
a
way
to
change
it
without
changing
the
digest
or
something
like
yeah
yeah.
There
you
go
to
me.
A
This
is
like
an
ideal
thing
of,
like
we've
talked
with
the
what
the
references
is
like
if
you
slap
something
to
it
with
the
type
instead
of
a
signature
and
s-bomb.
Now
it's
like
support
info,
like
so
show
me
all
the
support
info
information.
So
if
somebody
did
attach
a
new
like
support,
info
blob
or
object
on
something
and
say
actually
we
bumped
out,
you
know
bumped
out
the
extension
like
we're,
supporting
this
thing
for
another
three
months
that
they
could
just
build
into
the
client.
A
B
Yeah
I
like
the
idea
of
especially
because
I
feel
like
a
lot
of
the
organizations
do
this
are
just
going
to
sign
their
images,
and
so
that's
part
of
the
signature
of
hey
we've
signed
this.
Our
signature
lasts
for
x
months
and
we'll
come
back
later
on
and
re-up
that
later.
B
B
B
A
A
B
A
A
A
Every
time
that
somebody
opens
that
link,
it
starts
recording.
So
usually,
when
I
come
in
here,
there's
like
lots
of,
I
guess
it.
I
guess,
unless
the
moderator
has
to
click
this
button,
I
guess
that
would
be
the
difference,
because
you
wouldn't
want
any
time
somebody
clicks
on
it
to
go
straight
to
the
youtube
yep.