►
From YouTube: [OCI-WG] Reference Types - 2022-05-03
A
B
Not
a
great
not
a
great
day
in
in
history,
that's
for
sure.
A
I
I
feel,
like
I
feel,
like
people
find
a
way
around
obstructions
in
general,.
A
And
I
don't
think
any
amount
of
you
know
any
amount
of
obstructions
going
to
stop
people
from
getting
what
they
need.
C
Can
you
all
hear
me,
I
think
this
is
working.
We
hear
you
excellent
thanks.
C
B
A
That
can
be
note-taker
this
time,
but
maybe
depending
upon
whether
brandon's
not
gonna,
show
up
so
maybe.
B
B
Yeah
seeing
a
few
nods
there,
yes,
please!
Yes,
please,
okay,
if
anybody
would
like
to
share
it.
Otherwise
I
will
just
kick
it
off
and
hold
that
position.
B
B
Please
add
your
name
as
an
attendee.
That
would
be
great
and
we
have
nisha.
Thank
you
very
much.
Nisha
gold
medal
to
you
for
being
a
designated
note.
Taker
really
appreciate
that
we
have
a
few
agenda
items
here
that
we're
going
to
get
into
and
before
I
start
is
there
anything
else.
I
just
want
to
ask
folks
this
is
going
to
be
recorded
and
posted
to
youtube.
So
please
be
kind
with
your
words.
B
This
falls
under
the
code
of
conduct
and
please,
if
you
have
questions
we'll,
try
and
maintain
order
and
flow
of
conversation
through
the
raising
of
hands
using
the
click,
reactions,
click
raise
hand
and
we'll
focus
the
discussion
through
that.
That
would
be
fantastic.
Thank
you
very
much
anything
else
before
we
get
into
it.
B
Nope,
okay,
excellent,
so,
first
agenda
item
is:
we
have
discuss
proposal
e
and
there
is
a
sub
bullet
under
there
modify
existing
image,
spec
sergey.
D
So
this
is
kind
of
continuing
last
week's
conversation
specifically
about
what
is
the
expectation
from
modifying
the
image
spec
and
adding
a
reference
field.
What
do
you
want
existing
registry
operators
to
kind
of
like
interpret
the
spec
as,
for
example,
there
is
a
there's,
a
section
in
proposal
e
that
states
that
if
the
reference
field
is
there,
then
the
reference
api
or
the
references
api
needs
to
return.
This
manifest
as
well.
D
So
a
couple
of
points
I
wanted
to
call
out
and
ask
about
that
was
if
we,
if
we
were
to
implement
this,
there
is
a
an
amount
of
work
that
needs
to
be
done
on
the
operator's
side.
For
example,
we
expect
the
references
field
to
be
descriptors,
which
kudo
could
not
be
a
breaking
change
depending
on
how
we
parse
it.
D
D
This
mix
of
hybrid
apis,
because
the
argument
of
adding
an
existing
field-
and
it
not
changing
the
spec,
doesn't
actually
hold
true
because
it
is
actually
coming
out
as
a
entry
into
the
new
api
and
so
registry
operators
definitely
do
need
to
change
it
to
get
the
new
api,
and
should
we
keep
them
separate
and
clean,
or
should
we
kind
of
like
have
this
migration
part?
But
I
think
the
migration
part
is
also
a
good
story,
because
brandon
mentioned
that
so
giving
this
will
give
our
ability
to
migration.
C
So
I
think
I
have
a
specific
answer
to
your
question
and
a
general
answer
to
the
general
class
of
questions.
This
specific
answer
of
what
should
a
registry
operator
do
with
when
it
gets
a
reference?
You
know
a
new
reference
field
and
an
image
manifest.
It
doesn't
know
what
to
do
with
it.
C
A
registry
operator
today
should
ignore
it,
as
under
the
spec
as
like
new
fields,
ignore
them
store
them
and
there's
a
there's,
a
tricky
intermediate
time
where
it
means
something,
but
this
registry
doesn't
know
it
means
something
yet
right,
and
I
think
that's
really
the
like
interesting
part
right.
I
think
we
should.
I
think
we
should
make
this
part
of
the
spec
or
at
least
part
of
the
official
written
down
discussion
of
the
of
the
spec
changes
we're
proposing.
C
We
should
say
registry
operators
should
signal
in
some
way
references
pushed
before
this
time
before
this
date.
Before
this
you
know
year
month,
something
it
doesn't
have
to
be
a
time
stamp.
References
pushed
before
this
date
will
not
be
indexed
and
will
not
be
available
in
the
referers
api.
C
If
you
want
to
get
those,
then
you
have
to
re-push
it,
and
so
only
on
you
never
have
to
like
go
back
and
crawl
all
manifest
to
find
anything
that
has
a
reference
and
recall
them.
You
could
just
say
you
know
after
you
know,
october,
1st
or
whatever
date
that
you
know
your
particular
registry
decides
to
launch
support
for
this
anything
before
that.
You
may
push
a
reference.
You
can
push
a
reference
today
and
it
will
be
ignored
and
not
indexed.
C
If
you
push
it
after,
we
officially
launch
support,
we
will
promise
to
put
it
to
return
that
in
the
referring
the
referrals
api.
That's
the
specific
question,
the
specific
answer
to
that
question.
I
think
we
can
discuss
whether
we
think
that's
a
good
idea.
The
general
class
of
a
problem
is
the
spec
says,
ignore
fields
ignore
unknown
fields,
but
it
doesn't
say
what
to
do
when
that
field
becomes
meaningful
right.
We
had
the
same.
We
had
a
lot
of
the
same
discussion
around
the
data
field.
C
C
I
don't
remember
whether
it
was
a
must
or
should,
but
like
should
be
the
base64
encoded
content
of
that
blob,
and
so
there
was
a
question
also
about
should
registries,
ignore
that,
should
it
go
back
and
enforce
that
anything
that
was
pushed
with
data
like
matches
that
I
think
we
should
consider
as
part
of
all
of
this,
making
an
update
to
the
spec
to
the
to
the
image
back
to
say
not
just
ignored,
but
like
beware,
the
semantics
of
that
might
change
if
you've
pushed
data
as
a
number
you
might
not
be
allowed
to
tomorrow,
because
we
might
say
it
must
be
a
string
or
if
you've
pushed
to
the
reference
field
as
a
string
that
might
break
tomorrow,
because
we
might
enforce
and
require
that
it's
you
know
an
object,
a
descriptor.
C
I
think
that
would
help
us
make
these
sort
of
changes
in
the
future.
Like
I
think
in
in
practical
usage,
that's
already
the
way
it
is
practically
speaking.
Nobody
is
pushing
a
reference
field
today,
but
if
some
silly
joker
was
watching
these
meetings
and
knew
that
a
reference
that
a
reference
field
was
coming
and
was
like,
I'm
going
to
show
them
I'm
going
to
push
it.
You
know
push.
C
String
and
that'll
really
show
them.
We
just
need
to
document
a
little
more
clearly
that
it's
not
just
ignored,
like
registry
operators
should
ignore
them
and
store
them
whatever,
but
also,
if
you
happen
to
be
pushing
one,
we
make
no
guarantee.
The
spec
makes
no
guarantee
about
the
behavior
of
that
it
might
it
for
the
registry.
It
shouldn't
crash
the
server.
Please
don't
crash
the
server,
but
for
clients
like
the
client
might
just
completely
barf.
If
it
is
asked
to
pull
a
manifest
of
a
type
that
it
doesn't
know.
C
I
think
I
think
that
is
the
general
solution
to
this
class
of
problems,
which
I
hopefully
think
we
will
make
more
of
in
the
future,
as
we
add
more
functionality
and
fields
to
existing
types.
That's.
C
D
Right
and,
and
so
if
we,
if
we
clearly
call
out
that
the
reference
field
may
or
may
not
be
honored
depending
on
certain
criterias.
D
That
part
should
be
probably
cleared
up
like
there
is
a
edge
case
where
things
might
not
work
with
using
the
reference
field,
and
what
I
was
trying
to
kind
of
like
ask
brandon
is:
should
we
just
go
with
the
new
manifest
and
for
scenarios
where
registries
don't
support
fall
into
the
reference
thing?
Is
there?
Is
there
a
proper
path?
D
I
get
that
registries
wouldn't
support
this
immediately,
but
show
them
the
right
way
tell
them.
This
is
the
direction
in
the
future,
and
then
yes,
we
have
a
time
where
we
need
to
stick
with
the
image
manifest,
but
we
recommend
everybody
to
kind
of
go
to
the
new
manifest
and
the
new
way
of
querying
the
references
without
having
to
go
back
and
forth.
D
That's
kind
of
what
I
was
trying
to
say
give
the
intent
of
what
the
specification
is
meant
for
which
is
guide
the
proper
usage
or
proper
direction,
because
the
spec
reads
in
the
reverse
order:
right
now:
do
the
image
manifest
and
then
hey
by
the
way,
there's
also
an
artifact
manifest.
Instead,
if
we
can
rewire
the
priorities
of
house
when
somebody
comes
and
reads
the
specification,
it
might
make
sense.
That's
that's
what
the
motivation
was.
C
Yeah,
I
I
think,
I
think,
removing
that
step,
removing
the
image
spec
the
modified
image
spec
notch
makes
the
learning
curve
too
hard,
not
look,
not
learning
curve
the
implementation
curve
too
hard
registry
operators
have
to
go
all
the
way
from
image
spec
today,
which
they
support,
happily
to
a
whole
new
type
and
whole
new
storage
and
whole
new
indexing
and
whole
new
everything,
and
that
is
going
to
be
hard.
It's
hard
to
motivate
it's
not
hard
to
implement
it's
hard
to
like.
Why
should
I
put
two
people
on
this?
You
know.
D
I'm
actually
scared
to
touch
team
inspect
because
you're
going
to
parse
fields
that
are
there
and
there
you
introduce
one
regression,
that's
going
to
blow
the
entire
a
multi-tenant
service,
so
it
might
sound
easy.
But
it's
not
that
easy
right.
You
want
to
test
every
path
and
have
negative
cases
and
whatnot.
So
that's
why
I
wanted
to
kind
of
like
make
sure
what
is
the
p0
that
we
need
to
validate.
If
we
say
that,
okay,
incrementally
we
need
to
kind
of
do
both
or
which
direction
do
we
need
to
go?
D
C
I
I
think,
that's
why
it
is
that
exact
example
is
why
it's
important
that
we
support
something
that
doesn't
require
a
new
artifact
type,
because
we
can't-
I
mean
like,
like
you
and
I
and
the
folks
in
our
immediate
bubble,
can
promise
can
pinky
promise
to
support
this
at
some
point
in
the
future,
but
there's
a
hundred
other
registry
operators
that
are
not
in
this
room
and
aren't
part
of
the
discussion.
So
we
have
to
have
something
that
works
right.
Whether
or
not
docker,
however,
supports
it.
D
Right
and-
and
the
only
point
I
think
is-
should
we
have
the
reference
api
also
index
it?
That
is
where
the
the
middle
ground
that
I'm
trying
to
draw
in
terms
of
agreed.
We
can
support
extended
fields,
data
fields,
because
the
data
spec
is
written
in
such
a
way
that
we
don't
have
to
do
anything
with
it
right,
like
registry
operators,
just
ignore
it.
If
it's
a
problem,
it's
a
problem
on
the
client,
but
this
one
is
actually
telling
change
the
server
behavior.
So
this
is.
C
A
little
bit
more
gray
than
that
in
that
case
I
think
that's
why
it's
important
that
that
registry
operators
signal
the
references.
The
reference
field
will
continue
to
be
inject.
You
know
you
can
push
to
us
a
reference
field.
You've
always
been
able
to
if
you're
conformant,
but
only
after
this
date
will
it
be.
Actually,
you
know
considered
as
a
you
know,
used
for
any
semantic
information
and
for
docker
hub
that
date
might
be.
Never
you
know
like
they.
C
Don't
they
might
never
do
it
or,
or
you
know
any
random
registry
that
on
the
internet
might
never
do
it,
and
so
they
just
won't
have
a
date
that
says
after
this,
when
you
push
this,
you
can
also
pull
it
from
here,
but
then,
when
acr
supports
it
or
gcr
or
whatever
they
can
say,
you
know
it's
october,
1st
we've
we
promised
to
to
you
know,
listen
to
those
references
when
you
push
them,
that's
right
sounds
good.
A
So
is
there
a
follow-up
action
item
that
needs
to
come
out
of
this.
C
Yeah
I'd
say,
I
think
I
think
two
things
came
out
of
that
one
was.
We
need
to
describe
this
situation
better
in
the
in
proposal
e
describe
like
what
happens
if
somebody
pushes
a
reference
field
because
they
got
it
from
some
other
registry
they're
pushing
it
to
you
now
and
you
don't
know
what
it
means,
or
you
know
you
don't
make
any
meaning
out
of
it.
C
We
need
to
document
registry
providers
should
say
the
reference
field
will
be
ignored
until
it
will
be
considered
ignored
until
after
some
date
where
it
starts
to
matter
the
other.
One
is
the
longer
term
in
general,
we
need
to
add
to
the
image
spec
unknown
fields
are
not
just
ignored,
but
also
may
change,
meaning
and
breaking
ways
in
the
future.
C
As
we
add
new,
meaningful
fields
does
that
do
people
agree
with
both
of
those
things
I'm
happy
to
take
on
doing
both
of
those
things,
but
I
don't
want
to
do
it
if
we're
just
going
to
argue
in
prs
after
this.
C
Okay,
I
mean
I'm
I'm
happy
to
argue
with
image
spec
folks,
not
in
this
meeting,
but
if
any
of
us
disagree
I'd
like
to
talk
about
it
now,
so
that
we
don't
so
that
we
sort
of
present
a
unified
front
to
which,
whichever
image
spec
maintainer
takes
a
look.
C
Can
you
summarize
those?
What
were
those
two
points?
Again?
Sorry
I
was
having
yeah
sure
the
one
was
for
references
specifically
in
proposal
e
reference
registry
implementations
should
say.
C
Even
if
you
push
a
reference
to
us,
we
will
ignore
it
until
after
some
date
for
that
date,
maybe
never
for
docker
hub
or
something
you
know
for
random
josh's
registry
or
something
that's
one.
Two
is
image,
spec
should
add
language
that
says
unknown
fields
are
not
are
ignored,
continue
to
be
ignored
and
accepted,
but
also
the
semantics
of
those
fields
may
change
in
future
revisions
to
the
spec.
Beware,
you
know
like
don't
you
can
put
anything
in
here,
but
the
semantics
of
that
may
change
in
working
ways.
C
E
E
You
know
issues
in
the
future,
whether
that's
like
security
or
data
loss,
or
you
know,
I
think,
we've
seen
we've
seen
examples
of
this,
where
the
spec
allowing
unknown
fields
introduces
vulnerabilities
that
we
didn't.
We
didn't
really
understand.
C
E
Think
the
the
being
able
to
confuse
a
manifest
list
for
a
manifest
was
oh
sure,
a
good
example
of
sort
of
you
know,
ecr,
not
accep,
not
accepting
unknown
fields
made
us
not
susceptible
to
that
specific
vulnerability.
Right.
E
Splitting
again
sure
admitting
we're
not
performant,
but
also
like
you
know,
you
start
accepting
data
with
references.
That
means
things,
and
I
think
that
there's
there
is
value
in
saying.
If
we
don't
understand
what
this
is,
if
we
don't
for
not
able
to
understand
the
semantic
meaning
of
something
that
if
you
push
it,
you
are
going
to
have
a
bad
experience
like
you
are
going,
maybe
you're
gonna,
maybe
something's
gonna,
be
cleaned
up
that
shouldn't
or
maybe
yeah.
C
I
don't
know
there
is.
There
is
always
the
escape
patch
that,
like
the
the
spec
in
general,
is
just
what
all
registries
and
clients
sort
of
generally
agree
to
the
general
shape
of
what
we
agree
to.
If
ecr
wants
to
say
we
don't
like,
if
you
could
write
code,
you
may
already
have
code
that
says
if
reference
is
in
there
block
it,
because
we're
extra
conservative
about
what's
coming.
C
E
C
C
Do
those
two
items
sound
good?
I
can
make
a
stab
at
doing
those
offline
if
we
think
those
are
good
thumbs
up
now.
All
right
thanks.
B
Yeah,
I
said
thanks
jason,
I
think
it's
interesting.
It's
always
the
timeless
discussion
of
precedence,
of
not
versioning,
apis
and
jamming
fields
in
and
what
that
means
over
versioning
them.
It's
the
you
know
the
age-old
question
of
the
right
way
to
change
things
over
time
and
whatever
you
document
here
will
be
the
precedent
that
we
have
to
leverage
in
the
future.
B
B
Excellent
all
right
next
one
is
new,
manifest
update,
so
this
is
kind
of
just
a
high
level
thing
I
was
just
reading
through.
You
know
the
state
of
proposal
e
and
taking
a
look,
and
I
went
back-
and
I
was
thinking
you
know
when
we
originally
introduced
proposal
a
there
are
a
few
questions
on.
Why
didn't
we
just
take
the
new
manifest
from
proposal
a
and
put
it
in
wholesale,
and
I
was
trying
to
reconcile
the
differences
between
them.
But
then
I
found
myself
asking
the
same
question
right
from
memory.
B
I
think
it
was
nisha
and
josh
just
saying
why
can't
we
just
put
the
the
new
manifest
for
proposal
a
in
proposal
a
so
one.
I
just
wanted
to
ask
that
question,
because
it
was
just
hard
for
me
to
mentally
map
going
through
things.
The
changes
there,
and
I
don't
know
that
I
ever
had
an
explanation
as
to
why
there
were
just
these
little
changes,
which
may
be
fine,
but
it
was
more
just
around
explanation
and
if
there
is
questions
about
that,
should
we
just
adopt
the
new
manifest
from
proposal.
A
into
proposal
e.
B
So
if
it
was,
if
I
just
came
along
and
read
it
as
a
drive-by
in
proposal,
a
it
lacks
a
little
bit
more
substance,
so
I
have
to
go
back
to
proposal
a
to
look
at
where
it
came
from
the
heritage
of
that
and
then
mentally
translate
fields
that
are
and
are
not
present
to
look
at
the
outcomes.
So
I
was
just
like
you
know.
Is
that
really
what
I
should
do?
Should
we
put
more
on
proposal
e,
or
should
I
just
take?
B
C
So
I
don't
have
a
super
strong.
I
don't
have
a
strong
horse
in
the
race
of
whether
we
use
subject
or
reference,
or
you
know,
teapot
or
whatever.
If,
if
you
think
it
would
be
useful
to
have
a
section
in
proposal
e
that
is
meaningful
dips
from
proposal
a
like
it
says,
sort
of
like
we
took
the
the
good
parts
of
proposal
a
and
the
good
parts
of
none
and
that's
a
value
judgment.
We
took
parts
of
each
of
these
things
except
the
thing
we
took.
We
also
renamed.
C
If
it
you
see,
if
you
think
it
would
be
helpful
to
have
a
description
of
why
we
thought
that
was
worthwhile.
I
think
that's,
that's
fine.
C
I
don't
know
if
I
think
brandon
is
probably
the
person
to
answer
those
questions
and
he's
not
here,
but
I
I
also
don't
know
if,
if
it's
well,
it
might
be
not
meaningful
or
it
might
be
meaningful
to
the
image
spec
maintainers
or
the
spec
maintainers
in
general
that
we're
trying
to
propose
this
to
eventually
because
they
might
say
I
don't
care
about
these
paragraphs
of
why
you
named
this
thing
this
instead
of
this,
or
they
might
say
well,
why
didn't
you
call
it
subject?
Subject
is
a
way
better
name.
C
Oh
there's
already
three
paragraphs
of
text
here
to
explain
that
to
me.
So
I
guess
I
don't
know
if
it's
useful,
that
doesn't
mean
not
to
do
it,
but
I
think
the
target
audience
is
the
folks
we're
going
to
propose
this
to.
If,
if
we
write
that
text,
the
target
audience
isn't
us
among
here,
I
think
we
generally
either
understand
or
don't
care
it's
folks.
You
know
when
writing
a
document.
The
target
audience
is
is
useful
and
I
think
that's
the
target
audience.
We
should
write
for.
B
Yeah,
I
I
agree
with
that.
I
think
you
know
if
I
again
take
what
you
said
and
and
play
it
back.
I
think
the
example
of
the
new
manifestos
weak
in
proposal
e
and
it
doesn't
it's
not
really
load
bearing
as
to
why
so.
It's
just
basically
here
are
the
top
level
fields,
whereas
the
you
know,
the
other
proposals
are
very
well
thought
out
and
represented.
B
So
I
think
at
a
minimum
we
should
try
and
at
least
flesh
out
the
examples
and
have
worked
examples,
because
you
know
when
I
read
through,
I
read
through
proposal
right
before
this.
It's
very
clear
about
annotations
and
you
know
the
the
new
properties
in
the
image
spec.
But
then,
when
I
go
down
to
the
it's,
just
basically
just
a
skeleton
without
an
example,
so
just
it
doesn't
look
like
it
bears
much
meaning
it's
like
well
what
you
know.
Why
is
this
and
then,
when
I
was
like
well
I'll,
write
this?
B
I
can't
actually
write
it
because
I
don't
know
why
the
fields
have
changed
because
yeah
I
have
the
pres
representation
from
a
and
it's
like.
Well,
I
don't
know
why
artifact
type
was
removed.
You
know
at
least
to
be
able
to
write
it
down.
I
have
a
high
level
that
you
know
brandon
didn't
think
it
was
anything
that
required
filtering
on
or
was
worth
storing
there
and
it
could
be
stored
in
annotations
and
then
just
the
the
renaming
subjects.
Reference
item-
that's
probably
less
important,
but
there
were
just
a
few
pieces
of
you
know.
B
Maybe
the
action
item
is
just
feeling
filling
out
the
example-
and
I
know
we
try
to
be
very
succinct
in
not
putting
too
much
in
there.
But
if
I
look
at
the
weight,
the
weight
is
on
all
the
work
in
the
image
spec,
but
nothing
on
the
the
new
manifest
and
the
or
even
the
api
endpoint
that
we're
proposing
to
query
these
things.
So
I
just
think
shoring
that
up
in
general
would
probably
be
a
good
thing.
B
Well,
I'll
take
it
as
an
action
item
when,
when
brandon's
back
just
to
do
that,
if
we
think
that
that's
the
case-
but
I
was
just
taking
the
lens
of
if
I
read
this
and
had
no
prior
knowledge-
does
what
we're
presenting
makes
sense
to
somebody
who
wasn't
in
this
room-
and
I
just
felt
the
the
new
manifest
piece
was
weak
in
the
context
of
proposal
e,
probably
becau,
not
because
of
intention.
It
was
because
everybody
had
context
from
proposal
a
that's
not
represented
in
proposal
a
but
yeah.
B
D
Yeah
actually,
jason.
Your
point
is
excellent,
like
using
what
the
maintainers
of
oci
or
the
image
spec
industry,
which
might
attach
to
right.
That
said,
last
week's
call
mike
brown
did
mention
about
bringing
the
extensions
api
as
a
way
to
kind
of
take
this
forward.
So
I
I've
been
trying
to
kind
of
like
get
this
on
brandon's
eyes
for
some
time,
so
maybe
that'll
happen.
The
other
thing
of
whether
we
should
use
subject
or
reference.
D
Like
you
said
it's
just
a
matter
of
whatever
we
propose.
It's
not
there's
no
strong
opinion
there,
whatever
works,
but
the
order
of
the
spec
is
still
kind
of
like
something
that
I
want
to
get
people's
eyes
on
in
terms
of
it
gets
really
complicated
in
terms
of
filtering,
and
should
we
take
this
entire
thing
or
should
we
trim
it
down
to
support
something?
Because
I
know
that
jason,
you
were
first
about,
let's
get
something
that
is
achievable
and
then
move
on
right.
D
It
probably
needs
a
little
bit
more
clarity
of
what
we
go
after,
at
least
for
an
mvp
or
a
v1
of
the
implementation
and
trim
it
down,
because
the
second
part
of
the
spec
is
a
little
bit
dent.
Now
I
wouldn't
say:
dense
it's
it's.
It
needs
a
little
bit
more
clarity.
That
can
help.
That's
that's!
That's
all.
I
have.
C
Thanks
rj
jason
yeah,
I
mean
I
think,
if,
if
comparing
the
new
artifact
manifest
part
of
e
to
a
makes
you
feel
like
e
is
lacking.
We
should
definitely
you
know,
bring
it
up.
I
don't.
I
don't
want
anything,
that's
not
up
to
that.
Up
to
that
level.
Sanjay.
I
didn't
quite
understand
the
extensions
point.
What.
D
Are
we
talking
about
so
I
mean
you've
been
in
those
calls
right.
Like
it's
been
about
almost
two
years,
we
kind
of
worked
a
way
in
which
we
can
add
new
apis
to
distribution
without
touching
manifest
you're
again
making
the.
So
the
this
proposal
will
modify
the
manifest
url
path,
which
is
something
that
I'm
a
little
concerned
about
again,
whereas
the
extensions
enables
us
to
route
it
to
something
entirely
different
and
not
touch
the
routes
at
all
for
the
manifest,
so
it
that
was
one
of
the
reasons
why
the
extensions
approach
was
discussed.
D
I
think
michael's
mike
brown,
also
kind
of
like
spoke
in
the
last
oci,
call
to
see
if
we
can
leverage
that
same
model
where
we
put
oci
artifacts
discovery
or
something
like
that
where
which
would
give
the
same
references
implementation
without
having
to
touch
the
manifest
path.
That
was
something
that
we
probably
wanted
to
adopt
to
to
e,
to
make
it
land
faster
without
touching
manifest
digest
and
then.
Finally,
the
referees.
C
Gotcha
sure
I
think
I
think
same
answer
about
the
name
of
the
fields.
If
that's
our
last
sticking
point,
I
will
gladly
give
up
if
you
want.
A
C
Yeah,
I
will
also
echo
your
agreement
with
my
point
about,
let's
cut
as
many
features
out
as
we
can
and
iterate.
If
we
get
something
through
the
spec
process,
without
filtering
and
without
pagination
or
whatever
then
stupendous,
we
can
add
that
later
I
would
like
to.
I
would
like
to
advocate
for
that
as
much
as
possible,
just
to
reduce
complexity
in
each
of
these
changes.
E
Yeah,
I
think
I
agree
with
exactly
what
you
said
there.
The
filtering
part
is
just
seems
hard
to
make
work,
and
especially
when
you
start
thinking
about,
I
think,
bigger
registries
might
be
able
to
figure
out
something
they
might
want
to
throw
a
bunch
of
people
at
it
and
and
build
some
fancy
index.
But
I
think
we
shouldn't
make
that
a
requirement
and
we
shouldn't,
I
think,
just
that
any
to
any
filtering
is,
is
more
than
most
use.
E
C
Yeah
I'll
just
say
we're
doing
a
dangerous
amount
of
agreeing
here.
Folks
we
need
to.
We
need
to
really
I
come
here
for
the
fights
and
we're
not
doing
nearly
enough
fights.
I.
C
No,
no,
no!
No!
That
was
a
joke.
That
was
a
joke.
Josh!
Sorry,
I
cut
you
off.
You
have
your
hand
up.
F
No
yeah,
I
agree
cutting
things
out.
I
think
proposal
e.
It
has
a
lot
of
strengths,
but
it
doesn't,
it
seems
to
get
lost
in
the
fact
that
there
is
so
much
on
the
filtering
and
it
just
it
doesn't
seem
necessary.
I
think
it
needs
to
focus
more
on
the
upgrade
path
from
a
registry
that
has
none
of
these
features
to
registry,
who
has
the
new
manifest
or
the
artifact
manifest.
F
So
I
don't
know
if
that
works
should
be
done
in
that
document
itself
or
somewhere
else,
but
I
think
we
need
to
start
thinking
about
upgrading
and
cutting
out
as
much
as
we
can
to.
You
know,
keep
the
agreement
in
at
a
maximum
here.
B
A
So
it
seems
to
me
that
there's
a
consensus
that
proposal
e
is
good
as
it
is,
but
it
must
be
broken
down
into
subproposals
that
need
to
be
proposed
one
after
the
other
is
does
that.
That's.
B
Not
what
I
heard:
that's
not
my
interpretation.
My
interpretation
is,
and
again
my
interpretation,
not
everybody's
is
that
we
need
to
strip
back
proposal
a
to
make
it
as
understandable
as
possible
to
an
audience
like
the
tob
to
understand
and
strip
all
the
complexity
out
of
which
we've
called
out
filtering.
I
called
out
making
the
manifest
just
a
little
bit
better.
It
worked
example
and
josh
called
out,
maybe
framing
it
in
hey,
I'm
a
registry
operator
today.
Here
is
the
upgrade
path.
B
This
is
what
you
need
to
do
today.
In
this
way,
you
need
to
get
to
sarjay
called
out
instead
of
messing
with
the
you
know
manifest
apis.
We
use
the
extension
mechanism,
that's
in
distribution
now,
which
was
in
proposal
a
and
in
proposal
a
it
landed
as
hey.
No,
no
we're
going
to
update
distribution
immediately.
B
So
what
I'm
interpreting
is?
Is
there
a
proposal?
E
prime,
which
is
you
know,
kind
of
goes
to
my
next
point
in
the?
How
do
we
start
to
coalesce
to
where
we
would
be
building
the
artifact
that
we
would
present
as
a
proposal
to
you
know?
I
don't
know
if
it's
the
oci
tob
or
if
it's
the
spec
maintainer,
I
don't
know
to
the
audience
that
needs
it
needs
to
go
to.
How
do
we
get
it
to
that
spot?
Which
is
my
next
point,
so
I
don't
know
I'm
going
to
pause
there.
B
F
So
my
understanding
is
that
the
tlb,
unless
we
are
creating
a
new
spec
which
maybe
the
man
the
new
manifest,
would
be,
I
think
we
can
bypass
entirely
from
tod.
That's
that's
my
understanding.
B
F
A
You
I'm,
I
was
waiting
for
someone
to
say
nisha.
You
can
talk.
B
A
I
may
not
have
been
clear
in
my
explanation
then,
but
it
seems
to
me
that
proposal
e
is
at
least
from
hearing
conversations
and
taking
notes.
Proposal
e
is
good
at
collecting
the
things
that
we
want
to.
We
want
to
upstream
in
the
end,
but
we
just
have.
A
We
have
to
figure
out
which
parts
to
upstream
first.
So
for
me,
it
see
from
what
I
am
seeing.
A
We
ought
to
start
with
proposal
with
the
the
image
changes,
so
the
new
artifact
and
then,
following
that,
we
we
put
the
filtering
part
in.
We
put
the
backwards
compatibility
with
the
registry
operators
getting
the
signaling
when
they
would
make
that
change
and
so
on
and
so
forth.
But
it
it
seems
to
me
that
that
the
the
new,
the
new
type
of
manifest
needs
to
go
away.
A
Needs
to
be
proposed
first.
B
Okay,
go
ahead,
I
would
just
say
I
don't
want
ordering
it's
like
presenting
a
change
to
law
and
they
say
actually
we
like
the
first
sentence,
but
we're
not
going
to
do
the
rest
and
I
just
get
worried
that
the
rest
is
going
to
get
bogged
down.
So
I
would
be
particularly
disappointed.
As
being
you
know,
some
of
the
one
of
the
authors
from
proposal
a
that
we
put
this
up
and
they
said
oh
yeah,
we're
gonna
make
the
changes
to
image,
but
that's
it.
B
Everything
else
is
gone
because
that's
actually
not
the
spirit
of
the
proposal.
The
other
thing
is,
if
you
stage
it
out,
knowing
how
these
things
work,
there
could
be
changes
of
government
halfway
through
this
and
people
don't
have
the
same
drive.
So
I'd
like
there
to
be
a
commitment
to
you
know,
I
don't
don't
have
the
authority
to
assert
this,
but
if
you
came
and
you
you
drafted
up
some
legislation,
you
wouldn't
say:
please
just
do
it
half
of
it.
B
You
might
be
able
to
present
that
back
and
make
an
agreement,
but
you
wouldn't
space
it
out.
I
worry
about
you,
know,
timing,
things
and
doing
things
when
obviously
it
is
touching
a
lot
of
different
parts
but
yeah.
I
wouldn't
want
to
do
that
because
I
know
how
that
game's
gonna
end
right
now,
which
is
the
new
manifest
won't
get
in.
A
Okay,
why
wouldn't
the
new
manifest
get
in.
A
This
is
true,
but
the
the
folks
that
did
push
back
were
registry
operators,
but
if
we
were
to
submit
the
image
spec
with
the
change
in
the
reference
and
say
that
the
registry
had
you
know,
registry
operators
or
to
or
should
communicate
when
a
field
is
recognized
or
unrecognized
etc.
Whatever
jason
said,
that
would
be
the
first
part
and
then
the
next
part
would
be
adding
the
the
artifact
manifest.
A
C
So
I
think
lucky
to
your
point
of
being
worried
that
if
we
stage
proposals
you
know
proposal
one
two,
three
or
whatever,
that
the
tob
or
whatever,
whoever
we're
proposing
this
to
may
say
we'll,
take
one
and
now
we're
kind
of
tired
we're
just
gonna,
stop
and
we're
not
to
do
two
or
three,
and
so
that
sounds
like
motivation
for
moving
one
and
two
into
one
proposal.
You
know
like
bundling.
C
I'm
specifically
not
saying
what
each
one
contains
so
that
it
doesn't
matter,
but
just
like,
let's,
let's
push
a
little
bit
more
towards
the
the
first,
the
first
cut
of
the
proposal,
so
that
they
don't
accept
one
part
of
it,
but
not
another
part.
We
like,
I
think,
that's
fine.
I
think
that's
that's
good
and
in
fact,
if
we
want
to
propose
the
new
artifact
manifest
and
the
image
spec
changes
at
the
same
time,
I
think
that's
a
reasonable
compromise
to
say
like
that.
C
You
know
here
is
the
upgrade:
it's
not
just
here's
two
proposals,
but
like
here's,
the
upgrade
path,
we
propose.
First,
you
start
with
image,
spec
changes
and
then
you
can,
you
can
add
these
artifact
manifest.
I
will
say
I
think
there
is
a
useful
thing
about
minimum
viable
things
which
is
like
it
prevents
over
engineering.
C
It
prevents
doing
more
than
the
user
is
asking
for,
because
you
know,
I
may
think
that
I
want
the
whole
sistine
chapel,
but
really
they
just
want,
like
you
know,
a
place
to
sit
and
pray
right
like
they
don't
need
the
whole
thing,
and
so,
when
I
build
them
a
little
room
they're
like
that's
enough
for
me,
stop
there
you
know
and
that's
not
necessarily
a
bad
thing.
That's
that's!
Maybe
the
best
thing
to
your
point
about
like
changing,
wins
and
tides,
and
things
like
that's
being
nimble.
C
That's
if,
in
a
year
from
now,
none
of
us
care
about
oci,
because
our
houses
are
all
on
fire
like
man,
I'm
glad
we
didn't
waste
any
time
talking
about
oci
stuff,
because
I
gotta
put
my
house
out.
You
know.
So
I
know
that
that's
not
a
very
satisfying
like
rebuttal,
but
I
think
if
we,
if
we
decide
not
to
propose
something
until
it's
all
of
the
stuff
that
makes
all
of
us
happy,
then
we're
never
going
to
do
it
and
it
might
be
more
than
they
want
to
approve.
Anyway.
C
If
we
say
here
is
the
minimal
thing,
we
all
mostly
agree
to.
That's
that's
cut
one.
We
can
even
preview
them.
Like
here's
cut
two
here's
cut
three,
then
I
think
that's
a
little
easier
to
get
swallowed
upstream.
A
And
I
believe
that
I'm
sorry,
I
lowered
my
hand
there
prematurely,
but
I
I
believe
that
the
last
time
proposal,
a
came
up,
one
of
the
pushbacks-
was
that
it
has
too
many
changes.
B
I
think
I
think
proposal
a
means
that
we
don't
have
too
many
changes
right.
It's
there
is
a
set
of
changes
on
the
image
spec
that
we're
outside
of
the
scope
of
what
proposal
I
had.
There
are
a
different
set
of
changes.
We
didn't
take
them,
we
so
we
took
the
stuff
from
you
know,
brandon's
approach.
I
think
it
was
d,
no
changes,
but
we
just
add
stuff
to
image
spec.
B
So
that's
kind
of
and
we'd
take
the
the
new
manifest
which
didn't
require
any
other
further
changes
to
the
image
spec,
so
they
would
then
be
decoupled,
and,
given
the
extensions
workers
landed
in
distribution,
we
even
decoupled
having
to
mess
with
distribution.
So
I
think
it's
the
you
know.
What
I
hear
is:
let's
just
put
the
proposal
together.
It
sounds
like
proposal.
A
is
is
a
good
good
point.
We
should
riff
on
the
bits
that
we
should.
You
know
we're
going
to
create
proposal
e
prime.
B
B
Here's
why
you
know,
maybe
a
few
things
around
why
we
think
these
endpoints
are
important
and
then
and
then
go
from
there,
but
I
do
want
to
start
to
move
us
in
a
direction
of
having
an
artifact
that
we
present
to
these
groups
and
it
sounds
like
we
are
coalescing
on
just
a
few
changes
to
e.
C
Yeah,
I
think
so.
I
would
like
to
agreement
sandwich
and
end
with
an
agree.
I
think
a
thing
I
think
we
all
agree
on,
which
is
that
filtering
should
be
deferred,
not
necessarily
excised,
but
like
not
now,
and
then
we'll
figure
it
out
later
so
should.
B
I
just
throw
up
an
issue.
I
agree
on
that.
Should
I
I
feel
like
what
the
conversation
we've
had
today
is
drop
filtering,
make
sure
the
new
manifest
proposal
has
a
worked
example
just
to
give
it,
and
you
know
we
can
further
discussion
about
what
whether
it
should
be
the
same
as
proposal
a
or
what
brandon
was
thinking
there
till
later
the
we
could
move
the
registry
endpoint
out
to
extensions.
It
sounds
like
both
michael
and
sergey
are
suggesting
that
that's
probably
a
better
place
for
that.
B
B
E
Okay,
I
I
I
think
we
sh,
I
mean,
I
think
we
should
suggest
an
end
point
for
this.
I
think
part
of
the
goals
of
the
working
group
is
to
provide
a
way
to
query
so
I,
if
there,
if
we
think
it's
better,
to
put
it
in
some
other
place
as
an
extension
endpoint,
that's
fine,
but
I
do
think
that
that
is
part
of
I
see
that
as
part
of
this
work.
C
I
think,
for
the
purposes
of
staging,
I
think
it's
the
whole
point
of
extensions
is
a
place
to
go
a
sandbox
to
go.
Do
whatever
you
wanted
and
if
we
do
whatever
we
want
in
there,
and
then
everyone
says
yes,
this
is
great.
Why
is
the
path
you
know
underscore
oci
extensions
and
not
slash
whatever?
Then
we
can
say:
listen,
we've
got
a
year
of
operational
experience.
Handling
this
endpoint,
I'm
happy
to
write
another.
You
know
url
path
to
make
it
called
the
other
way.
I
think
that's
fine
to
me
again.
C
I
don't
care
what
the
url
is
say
because
no
one
will
see
it.
Nobody,
but
the,
but
the
12
of
us
will
ever
see
it.
Your
secret
is
yeah.
B
C
Yeah,
I
think,
I
think,
for
practical
purposes,
we
should
just
modify
e
until
we're
all
happy
with
it.
I
don't.
C
A
proliferation
of
proposals
e
prime
and
e
prime
final,
no
really
and
whatever.
I
think
we
should
just
edit
e
until
we're
happy
with
it.
Does
anyone
disagree
with
that,
but
I
agree
with
the
shape
of
the
changes
you're
talking
about
absolutely
okay,.
B
Then
I'll
just
capture
that
and
we
we
riff
on
in
pr's,
in
line
with
those
things
we
can
pull
out
any
individual
pr's
and
let
brendan
brandon.
I
should
say
sorry,
sorry
brandon,
the
right
you
know
when
he
comes
back
he'll
have
context
for
each
of
these
movements.
It's
going
to
look
like
we're
all
working
as
one
based
on
that
issue,
so
I
can
go
create
that
issue.
We
can.
We
can
at
least
mention
what
the
big
outcomes
are
here
and
I'm
sure
brendan
will
be
brandon.
B
Sorry,
not
a
good
day
for
me
and
two
strikes.
Let's
see
if
I
can
go
out
swinging
or
looking
and
yeah
we'll
go
from
there.
D
F
Okay,
so
last
week
I
put
together
this
github
org
oci
playground
with
multiple
copyright
violations.
F
If
anyone
wants
to
be
added
to
this
I'll,
put
you
on
as
an
owner
no
problem,
so
the
goal
I
was
having
here
was
just
to
see:
if
proposal
e
even
works,
so
we
have
it
in
theory,
but
can
we
write
some
code
against
it?
So
I
decided
on
using
zot
and
ggcr
for
a
few
reasons.
F
Zot
both
of
these
projects
are
very
active,
so,
like
I'm
thinking,
we
could
get
input
from
the
maintainers
jason's
on
ggcr
rom
who
comes
to
these
calls
is
on
salt,
and
then
you
know,
full
disclosure
bias
chain
guard
is
doing
a
lot
of
internal
stuff
with
ggcr,
so
it
made
a
lot
of
sense,
but
if
we
want
to
like
bring
in
repos
here,
such
as
distribution,
distribution
or
us,
whatever
we
want
like,
we
can
use
this
design.
F
F
F
All
right
and
then
zot
keeps
like
an
index
of
like
an
oci
index
of
everything.
That's
in
there,
I'm
pretty
sure
other
registries
don't
do
it
this
way,
and
I
need
to
work
with
that
team
to
figure
out
how
best
to
do
this,
but
all
right.
So
the
first
is
creating
a
reference.
F
Using
the
reference
field
on
image
spec,
so
I'm
going
to
create
a
text
file,
hello,
txt
and
then
push
it
to
this
text
file
tag
and
this
kind
of
surface.
One
of
the
issues
I
found
is
like
to
make
a
reference:
do
you
need
a
separately
tagged
thing,
or
is
there
a
way
to
just
push
it
up
anyway?
So
this
does
that
and
then,
if
you
actually
look
at
the
manifest
for
this.
F
You
can
see
it
has
this
reference
field
here
and
then
in
the
index
like
in
the
storage
side.
This
is
the
part.
That's
very
dubious.
I've
like
this
was
not
in
the
proposal
at
all,
but
I
needed
a
way
to
somehow
link
the
thing.
So
I
came
up
with
this
annotation,
but
I
think
that's
an
implementation
detail
that
maybe
we
don't
need
to
even
discuss
but
worth
bringing
up
that.
This
is
how
I'm
linking
things
and
then
I
also
have
implemented
the
references,
endpoints
and
so
basically
and
hidden.
F
References
you
can
see.
This
is
returning
the
index
like
proposal
e
describes
in
with
the
with
the
manifest
there,
and
I
have
like
a
second
text
file,
just
to
show
that
it
really
does
work.
F
So
there's
two
there
now
yeah,
that's
that's
it.
I
mean
no
filtering
no
dumb
registry
to
smart
registry,
but
that's
sort
of
next.
I
want
to
make
sure
that
you
can,
with
this
fork
of
zod
and,
like
you
know,
I
don't
know
some
stable
like
ecr
or
something
like
push
from
one
to
the
other
with
the
new
stuff
and
the
old
stuff,
but
so
it's
mostly
doable.
I
haven't
done
anything
with
the
new
artifact
type.
C
B
G
F
So
you
you
post
a
manifest
that
has
the
reference
the
digest
of
the
manifest
that
you're
posting
and
push
I'm
putting
that
in
the
links
in
a
comma
separated
list.
Let
me
actually
here
I'll,
show
you
how
the
index
looks
now
like
this
then
cool
this
see
this
has
like
a
comma
separated
list,
so
this
is
obviously
not
the
right
way,
but
I
needed
a
way
to
loop
through
the
storage.
F
D
So
right,
that's
one
way
to
do
it.
You
can
also
index
it
by
artifact
type
as
a
directory,
if
you
want
to,
but
if
you
don't
want
to
care
about
filtering
those
are
the
multiple
options
that
we
chose.
It's
pretty
much
the
same
thing
right.
You
want
to
get
a
hive
of
all
the
references
for
that
specific,
manifest
in
some
way.
That's
what
you
end
up
doing
I
mean
those
are
just
a
couple
of
options.
You
can.
F
B
That
brings
us
to
the
end
of
the
meeting
and
the
agenda.
Thank
you
very
much
folks
and
please
add
any
agenda
items
for
next
week.
We'll
see
you
all
at
the
same
time
same
place
next
week.
Thank
you
all
go
and
have
great
days
cheers
everyone
see
ya.
You
too,
jason
bye,
bye,.