►
From YouTube: OCI Weekly Discussion - 2022-12-15
A
C
C
D
They
tell
you
what
happens
when
two
people
that
are
really
fluent
in
in
some
of
this
stuff
try
to
collaborate
on
a
talk
really
quickly.
I
wrote
a
deck
for
Phil,
Estes
and
I
to
present,
and
he
knows
this
stuff
so
well
that
he
kind
of
skimmed
the
deck
and
then,
as
you
do,
he
just
talking
he's
talking
basically
off
the
top
of
his
head
and
I'm.
Like
oh,
that's
like
three
slides
later,
oh,
no!
Oh!
No!
Because
that's
what
happens
right,
you
just
start
giving
the
time
like.
E
E
D
E
D
A
D
E
A
E
F
C
A
E
E
D
Speaking
of
voting
can
I
ask
a
random
question:
that's
not
on
the
agenda.
It's
mostly
just
planning
I
think
we
had.
We
had
set
a
target
for
January
30th,
we're
looking
at
the
1.1
version
of
the
specs,
and
if
there
wasn't
a
huge
issue
you
know
then
we
would
we
would
look
to
to
releasing
them.
130
is
not
Thursday,
like
should.
Should
that,
should
that
morph
back
into
like
January,
26th
or
or
like
the
following
February
day
or
or
is
that
more
like
we'll
bring
it
up
with
the
26
meeting?
D
E
Have
we
really
exercised
it
enough
to
say
hey
we're
good
if
we
do
if
we
go
good
early,
we're
likely
to
have
to
patch
it
and
if
there's
any
risky
changes
that
have
to
be
changed
now
we're
sort
of
stuck
because
we've
got
some
people
that
are
expecting
that
version
to
also
exist
and
if
there's
a
major
change
that
has
to
be
done
or
some
kind
of
breaking
change.
God
forbid,
then
we'd
have
to
go
to
1.2
right
away
right.
C
D
E
Let's
not
let's,
let's
get
a
little
more
exercise
on
it,
try
to
push
a
little
hard
from
the
side
of
we
want
to
GA.
When
are
we
going
to
get
a?
You
know,
a
bunch
of
clients
working
and
a
few
Registries
working
and
and
like
some
of
the
base
code
that
I
know
the
Registries
most
of
the
Registries
are
using
no.
E
G
E
What
maybe
I've
got
I've
got
some
work
going
on
with
one
of
the
maintainers
on
Helm
trying
to
get
them
to
actually
exercise
it
as
well,
so
not
just
on
the
clients
and
on
the
Registries.
But
actually
you
know
a
valid
use
case
for
somebody
who
was
on
RS
before
that
needs
to
migrate
over
if
and
when
welding.
So
that
would
give
you
that
pattern
as
well
I
think
I'm
being
less
aggressive
than
than
we
could
be.
But
that's
just
my
vote
just
my
opinion.
B
A
Yeah,
maybe
maybe
yeah,
because
the
other
thought
I
had
was
in
addition,
distribution
distribution,
we've
also
got
thicker
container
registry
out
there
and
I
think
they've
been
working
on
getting
a
PR
merch
on
that
side
as
well.
So
there
is
effort
from
a
lot
of
different
directions.
I
think
it's
just
a
lot
of
people
spread
pretty
thin
right
now,.
D
D
Yeah
did
did
that.
Did
we
have
a
follow-on
conversation
because
I
I
was
at
the
oci
Summit
AT,
kubecon
and
I?
Don't
I,
don't
recall,
sort
of
changing
this
plan?
I
I
understand
it
when
we
first
when
we
first
said
well,
let's
pick
a
date
that
was
sort
of
the
main
concern
was
like.
Well,
we
have
enough
time
for
compliance.
Well,
we
have
enough
time
for
clients,
but
the
flip
side
is,
you
know
at
least
speaking.
D
You
know
representing
I
mean
here:
I
represent
Jesse
Butler,
but
you
all
know
I
work
on
ECR
right,
so
so
ECR,
you
know
we
ship
production
features.
That's
what
we
ship.
We
don't
have
an
option
to
do
like
developer
preview,
so
we've
been
doing
development
alongside
this
whole
entire
time
and
we're
basically
sitting
behind
some
feature
Flags,
so
that
when
we
have
a
ga
spec,
we
turn
it
on.
D
The
problem
is,
is
that
until
then,
we
can't
really
turn
it
on.
We
can't
risk
sort
of
the
data
model
changing
based
on
spec
changes,
and
then
we
have
customers
stranded
with
things
that
would
be
corrupt,
so
we're
kind
of
like
we're.
The
flip
side
of
that
Queen
is
like
we're.
If
you
want
a
very,
very
large
registry
to
be
part
of
this
adoption,
we
can't
do
it
until
we
have
a
spec
until.
E
D
D
H
A
H
Is
perpetually
a
half
done
PR
that
I
need
to
give
more
attention
to
to
get
that
done?
I've
told
people
I'll
get
that
done
by
the
end
of
the
year,
but
my
God,
it's
close.
The
I
I
would
like
to
cut
a
1.1.
I
would
also
like
to
make
sure
that
everybody's
concerns
are
I.
Think
there
are
a
number
of
concerns
that
have
been
raised,
that
we
should
at
least
acknowledge
and
say
no
we're
going
to
cut
1.1
anyway,
like
explicitly.
H
This
is
not
a
thing
we're
doing,
but
otherwise,
like
yeah,
I,
guess,
I
guess.
My
question
to
Jesse
and
Sanjay's
crinkled
nose
and
slate
nod
is
how
how
willing
are
you
for
1.1
to
change
or
the
thing
we
would
call
1.1
to
change
in
slight
ways
before
we
cut
a
1.1?
Is
that
going
to
cause?
You
know
a
month
more
of
work
for
you
a
day
more
of
work
for
you
20
minutes
more
of
work.
H
It
good
or
bad
the
the
specific
thing
is
hoisting.
The
annotations
right
I
think
that
was
that
was
the
sort
of
most
recent
and
largest
ish
sticking
point
is
that,
for
example,
something
that
would
set
you
back
three
months
or
is
that
something
that
would
set
you
back?
You
know
a
week
or
a
release
like
you
know,
like
one
I,
don't
know
how
long
Amazon's
releases
are,
but
like
one
release.
H
H
We
talked
about
I
think
a
couple
weeks
ago,
not
because
not
even
because
I
have
an
urgency
to
like
answer
those,
but
because
the
sooner
we
answer
those
the
sooner
the
clock
starts
on
your
you
know,
order
of
weeks
before
you
can
roll
this
out,
so
I
don't
want
to,
or
if
we
all
talk
about
it
more
and
decide
that
we
are
going
to
do
the
thing
that
we
already
said
we're
going
to
do
then
at
least
we'd,
like
you
know,
decided
it.
I
just
feel
like
there's
a
dangling
open
thread
of
like
hey.
H
Some
folks
have
expressed
some
issues
with
the
API
as
currently
specified
and
I.
Don't
want
to
rush
a
1.1
out
the
door
and
lose
the
lose
that
thread
right,
not
rushing.
It
sounds
bad,
but
you
know
what
I
mean
like
I:
don't
want
to
cut
it
because
we're
ready
to
cut
it
and
let
those
those
threads
dangle.
D
Yeah
I
completely
agree
and
that
that's
sort
of
why
I
did
I
am
it
might
have
sounded
hand.
Wavy
I
didn't
mean
it
to
you
know
without.
Without
you
know,
without
progress
on
those
threads
I,
don't
think
anybody
should
be
thinking.
Oh
yeah.
Well,
let's
just
cut
us
back
right.
I
think
we
want
to
work
and
that's
kind
of
what
I
was
asking
is
like.
What's
the
actual
date,
what
are
we?
D
Oh,
that
was
me.
Sanjay
I
was
gonna
actually
say.
Is
it
okay?
If
I
put
everybody
in
the
agenda
so
like
participants,
so
yeah
so
I
think
I
completely
agree.
Jason
I
think
we
need
to
make
sure
that
folks
aren't
super
concerned
about
some
of
those
threads
and,
if
they're
not,
then
maybe
we
time
box
some
of
those
you.
D
Did
with
the
proposals
in
the
working
group,
it's
like
you
know
we
can
keep
going
forever,
but
as
we
go
right
as
these
weeks
and
months
take
by
there's
time
that
you
know,
client
developers
might
be
doing
stuff,
Registries
might
be
implementing
and
other
registries
will
be
implemented
and
holding,
and
that
that
is
us
right.
That's.
H
Right,
the
time
box
tactic
is
useful
for
I
I
am
explicitly
not
naming
any
names
or
or
any
organizations
that
we
may
or
may
not
be
currently
talking
about
right
now,
but
sometimes
like
people
sort
of
circle,
the
solution,
but
never
quite
hit
it
and
feel
a
little
bad
about
cut.
You
know
deciding
to
be
close
enough
and
I
think
time.
Boxing
is
useful
to
be
like.
Listen.
If
we
haven't
come
up
with
like
serious
concerns
by
December
15th,
then
we're
cutting
it
like
unless
you
can
raise
some
serious
concerns.
H
I
think
that's
a
very
useful,
like
tactic
that
we
have
employed
well
in
the
past.
Your
point
is
good
right,
I,
think
like
having
a
time
box,
but
also
knowing
that
it's
not
like
there
is
a
robot
that
will
cut
this
on
at
midnight.
You
know
it's
all
humans
here,
we're
all
gonna
like
sleep.
We
need
to
slip.
H
That's
that's
a
good
point.
I
think
the
the
the
current
state
we
are
in
is
that
some
concerns
have
been
raised,
but
none
sort
of
loudly
or
consistently
or
push
back
early
enough
to
be
heard
to
be
like
you
know,
iterated
on
and
like
you
know,
whatever
their
concerns,
allayed
and
I
would
like
to
do
that.
H
More
I
would
like
to
like
give
that
more
time
and
more
oxygen
to
see
those
those
things
out
so
that
we
don't
lose
them
I
I,
like
the
nightmare
scenario,
is
we
we
just
cut
it.
We
just
say
like
it's
close
enough:
we
cut
it
and
then
three
months
later
we're
like.
Oh
all,
of
those
concerns
that
were
raised
before
vaguely
have
come.
True,
the
sky
is
falling,
Cassandra
was
right
and
we
should
have
listened
to
them
more
and
I'd
like
to
avoid
that
I
think
as
we
all
would
so.
H
I
would
like
the
the
actionable.
Actual
thing
is
for
the
people
who
have
those
concerns,
John
I
think
you
were
one
to
raise
them
more
specifically
and
more
loudly
and
push
back
more
I
can't
believe
I'm
asking
John
to
complain,
but
that's
a
joke.
Sorry,
everyone,
but
let's
let's
complain
more
about
those
things
so
that
we
can
Hammer
them
out
either
in
terms
of
fixing
them
or
saying
we're
not
going
to
fix
them
and
then,
as
far
as
I
know,
those
are
all
the
remaining
sort
of
things.
H
B
B
To
say
that
we
won't
release
it
if
there
is
no
GA
I'll
be
honest
with
that,
but
it
would
be
good
that
customers
don't
have
to
think
about
whether
parts
of
the
services
GA
or
not.
That
I
think
that's
a
statement
that
we
want
to
make
and
content
changing
content
that
people
have
created
is
very
difficult,
so
getting
some
amount
of
clarity
would
definitely
help
the
conversation.
H
I
think
a
good
thing
about
the
remaining
concerns
is
as
far
as
I
know,
based
on
my
latest
understanding
of
what
they
were.
It's
not
so
much
about
what
the
user
pushes
as
what
they
get
back
from
the
API
when
they
push
something
which
means
we
can
sort
of
fudge
it
right,
like
a
client,
still
can
push
the
same
manifests
they
might
just
get
a
new
response
from
the
refers
API
if
we
decide
not
to
hoist
annotations
or
whatever.
So
that's
at
least
a
good
thing
about
the
shape
of
the
the
open
outstanding
feedback.
H
But
yeah
I,
wouldn't
I,
wouldn't
I
I.
Also
yeah
I,
don't
want
to
put
you
in
the
situation
where
you
launched
something
and
then
we,
you
know,
change
something,
a
bunch
and
we
can
say:
oh
we
it's
fine
for
us
to
change
it
because
it
wasn't
GA.
Yet,
like
that's
a
real
like
trap,
right,
I,
don't
want
to
put
you
into
that
situation
or
anybody.
H
G
This
by
ghosty
has
never
been
this
case
of
like
oh,
it
has
to
be
GA
before
we
can
have
implementations
and
users
like
we
should
like
everything
should
be
perfectly
validated
and
GA
is
just
like
a
it's.
It's
just
like
a
stamp
like
it's,
it's
nothing
more
than
more
than
a
stamp
at
that
point
like
if,
if
there's
anything
wrong
like
if
GA
has
to
happen
before
implementations
and
implementation,
come
back,
say:
hey
this
isn't
good,
then
I
I
think
that's
not
the
way
oci
is
intended
to
work.
H
Yeah
yeah,
yeah
I
think
that's
smart,
I
think
so
the
important
thing
is
not
actually
calling
a
thing
GA
for
for
the
purposes
of
of
Jesse
and
Sanjay.
The
important
thing
is
sort
of
a
common
expectation
that
there
will
be
no
major
breaking
changes
to
the
API
that
we
have
laid
out
right.
That's
not
a
label
called
GA,
that's
just
sort
of
like
we
pinky
promise,
not
to
change
everything
and
call
everything
a
different
thing
now
and.
G
I
think
that's
a
I
think
that's
more
of
a
function
of
actual
usage
than
anything
else
like
the
point
is
that
these
these
specs
gain
momentum
to
the
point
where
there's
no
like
nobody
can
come
in
and
say:
hey,
you
know
what
I
don't
like
this
I'm
like
well,
too
bad
like
we're.
We've
already,
you
know,
we've
made
it
through
the
working
group.
We
have.
We
have
implementations
of
it.
We
have
proof
that
it's
working
like
if
you
have
proof
that
says
no,
this
isn't
working
then
I
think
that's.
That
shows
something
completely
different.
A
Yeah
I
I
share
the
strong
preference
to
seeing
some
implementations
out
there
in
the
wild,
so
that
would
be
helpful
just
to
have
everybody
comparing
and
trying
the
the
close.
Second
to
that
is
hearing
from
people
that
are
running
the
major
registry.
Saying
we've
implemented
this
we're
ready
to
split
the
switch
you've
got
a
green
light
from
us,
just
let
us
know
when
so,
not
quite
as
good
as
having
it
out
in
the
wild
and
having
actual
implementations
bang
on
it,
but
it
is
a
close
second
for
me,
Jesse.
D
Yeah
there
we
go,
yeah
I
completely
agree.
So
it's
it's
this
kind
of
Harkens
back
to
some
of
my
past
life
experience.
You
know,
I
fought
in
the
Unix
Wars
kids
and
you
know
we
had
a
lot
of
Open
Standards
that
we
did
and
nobody
shipped
them
early
right.
We
all
did
betas
and
we
all
kind
of
came
together
and
said
yeah.
This
is
working
for
our
customers.
This
isn't,
let's
fix
it,
and
then
we
had
a
spec.
Then
we
launched
a
thing
and
I.
D
Think
ECR
is
maybe
the
one
that's
closest
to
that,
because
we
don't
have
a
Dev
preview.
I
mean
I'll
just
hit
that
right
on
the
head
like
it
is
a
very,
very
large
registry
on
in
the
world,
but
we
really
can't
make
it
public.
We
do
have
an
implementation.
We
have
been
like
I,
said
running
alongside
for
people
that
joined
the
call
a
little
late
like
we've
been
running
alongside
with
implementation,
so
we
are
in
that
position
of
saying,
like
yeah,
we're
pretty
close
to
ready.
D
We
we
really
just
need
a
way
to
not
put
our
customers
in
a
position
of
using
something
that
then
changes,
and
then
you
know
we
have.
You
know
artifacts
that
are
abandoned
or
data
that's
corrupted,
or
we
have
to
do
this.
Massive
migration
move
so
I
think
that
sort
of
Json
harkening
back
to
what
you
were
saying.
I
think
that
that
does
align
right.
If
we're,
if
we're
in
a
position
to
say
yeah,
this
isn't
really
going
to
change,
it's
open,
we're
still
working
on
it
and
I.
Think
that's!
D
The
problem
for
me
is
like
well
what,
if
what
if
I
do,
have
a
pro
like,
not
me
but
like
what,
if
somebody
comes
along,
does
have
a
major
problem
with
it
and
they
call
it
something
that
none
of
us
thought
of-
and
we
say:
oh
actually,
we
can't
make
that
we
can't
keep
that
pinky,
promise
and
I.
Think
that's
the
risk
that
we
would
always
be
kind
of
coming
up
against
is
saying:
well,
it
could
change
so
yeah
I
mean
I,
I'm,
I'm
open.
D
You
know
as
a
member
here
to
just
do
what
we
all
think
is
the
right
thing,
but
I'm
trying
to
also
voice
this.
You
know
this
position
of
like
we're
more
like
from
the
olden
days
right
when
we
don't
have
a
facility
to
say
well,
let's
you
know,
let's
give
this
so
like,
even
if
we
did
a
beta,
it
would
be
a
private
beta.
We
don't
do
public
betas
right,
so
you
know
I
am
looking
at
things
like
zot
or
distribution
of
saying
like
well.
D
A
So
I
know
one
of
the
sticking
points
that
we've
come
up
with
in
the
past,
and
I'll
invoke
John's
ranting
or
John's
complaining,
which
is
the
concern
about
the
annotations
and
so
given.
There
is
concern
raised
about
annotations
and
I'll
save
John
from
even
having
to
make
the
rant
from
the
Registries
that
have
implemented
this
already.
Your
clients
are
using
it
already.
C
C
F
So
I
don't
want
to
say,
like
premature,
optimization
to
like
Hoist
the
annotations
up,
but
the
amount
of
like
engineering
work
that
I
would
have
to
do
to
support
that
versus,
like
the
amount
of
bandwidth
or
time
or
like
latency
saved.
By
doing
that
versus
just
like.
Embedding
the
entire
thing
in
a
descriptor
via
the
data
field
seems
like
not
worth
it
to
me
because,
like
even
if
we
just
return
to
scriptures,
not
even
having
like
artifact
type
or
annotations,
just
descriptors,
you're
saving
a
huge
cost
of
okay.
F
If
I
want
to
figure
out
like
what
references,
this
I
have
to
list
tags
and
then
like
listing
tags
for
certain
repositories,
takes
a
very
very
long
time
right,
like
we
paginate
several
thousand
things,
that's
very
expensive
to
generate
versus.
Okay.
Give
me
a
list
of
things
that
reference
this
artifact
all
right,
I'll
send
two
requests
for
that.
That
are
very,
very
cheap.
C
F
F
No
I
think
that's
too
complicated.
I
think,
like
the
data
field
exists
outside
of
the
refers
API
and
so
like
clients
should
be
able
to
handle
that
regardless
and
like
a
registry
might
do
both,
but
it
doesn't
make
sense
to
like
hoist
annotations
into
the
data
field.
Obviously,
but
like
I
feel
like
the
data
field,
is
there
for
this
purpose
already
and
it's
even
more
useful
than
just
having
annotations
and
yeah
yeah
I
I,
don't
like
having
to
like
index.
F
A
E
C
D
C
I
It
definitely
has
the
like
the
work
to
do
that
is
more
significant
than
not
doing
it
and
and
causes
a
lot
of
Yeah
you
sort
of
have
to
deal
with
like
okay.
In
most
cases,
the
annotations
are
going
to
be
a
reasonable
size,
but
it's
possible
that
they
could
be
really
big,
and
so
you
have
to
either
Implement
something
that
handles
those
cases
separately
or
just
do
something
that
is
always
going
to
work
for
the
big
cases.
But
it's
probably
not
going
to
be
the
best
for
the
small
cases.
B
Like
I
can
comment
from
the
ACR
site,
it's
pretty
much
the
same.
What
John
said
as
significant
amount
cost
to
Index
this
maintain
a
separate
index,
or
this
one
I
think
we
we
landed
on
the
cost
is
high.
Initially
we
didn't
want
to
do
the
annotations
as
well,
but
the
clients
found
it
without
querying
the
annotations.
B
It
was
not
going
to
be
useful
because
I
know
that
different
implementations
put
in
like
thumb,
prints
and
other
information
into
the
annotations,
and
one
thing
I
could
probably
ask:
is
there
a
middle
ground
where,
if
we
don't
return
the
annotations,
we
can
hint
that
the
annotations
don't
exist.
So
this
and
the
pr
currently
that
John
has
says
that
the
descriptors
may
include
the
annotations,
at
least.
If
we
can
deterministically
know
that
there
are
no
annotations
on
you
to
go
fetch
it.
That
might
be
a
reasonable
Middle
Ground
as
well.
F
B
Right,
we
did
the
filtering.
Similarly,
right,
like
we
felt
their
buy,
artifact
I,
think
that
was
Michael's
proposal
at
that
time.
So
if
you
have
a
similar
way
saying
that
yes,
Ambitions
are
not
included
and
you're
at
the
mercy
and
you
have
to
go,
pull
everything
back
or
did
a
field
is
not
embedded.
Those
behaviors
might
be
a
a
way
to
tell
the
clients.
Yes,
we
are
not.
They
have
to
do
something
extra.
A
A
B
C
A
A
B
Think
if
we
can
determine
that
there
are
no
annotations
and
we
don't
have
to
do,
and
we
have
to
do
the
extra
hop,
then
that's
that's
a
reasonable
compromise
right.
My
hope
is
not
I
I,
don't
I,
don't
actually
have
a
strong
opinion,
whether
The
annotation
should
be
there
or
not,
because
we
did
a
lot
of
the
heavy
listing
right
now
and
we
want
to
get
feedback
as
to
others.
Useful
or
not.
B
So
it
would
be
good
to
kind
of
like
at
least
clients
can
see
that
oh,
the
reference
API
didn't
return.
The
annotations
I
need
to
go
and
now
query
one
or
two
entities
like
I
agree
with
what
John
said.
I
don't
see
like
too
many
entries
being
attached
to
an
image
and
it
will
grow
over
time,
but
we'll
get
feedback
over
time,
hopefully
leads
toward
Auto
by
then.
A
A
E
I
E
F
E
F
On
the
subject
field,
which
is
fine
but
I,
wish
it
was
more
right,
I.
Think
in
our
like
starting
meetings
with
the
refers
API,
we
talked
about
like
querying
relationships
between
objects,
and
it's
like
a
very
abstract
thing
that
could
apply
to
a
lot
of
situations.
What
we
ended
up
with
is
like
querying
for
the
subject
field,
because
I
mean
pragmatically
it's
better
to
like
have
something
that
works
for
the
use
cases.
We
really
want
to
get
out
there,
then
to
like
stall
and
try
to
solve
garbage
collection,
but.
F
I,
don't
know
I
just
I,
don't
know
that
the
artifact
type
is
super
useful,
because
there
have
been
a
handful
of
examples
where,
like
the
artifact
type,
has
changed
because
it
was
wrong
and
is
arbitrary
and
like
what
does
it
mean
for,
like
the
media
type,
the
artifact
type
and
the
media
type
of
the
referred
thing
and
the
media
type
of
the
layer
like
what?
What
do
you
actually
do
with
that
as
a
client
Beyond,
just
having
a
hard-coded
list
of
things
that
you
would
expect
to
do?
F
E
F
E
E
F
E
F
E
Both
of
his
arguments
were
made
in
the
same
pull
request,
so
I
was
sort
of
guessing
that
they
were
related.
It
sounds
like
they
are,
maybe
more
use
cases
to
iron
it
out
and
then
and
then
maybe
it
would
be.
Okay
if
they're
lost,
because
he
would
see
the
you
know,
the
the
use
cases
need
that
to
happen.
Need
it
to
be
a
must.
Maybe
it
would
be
a
different
API
entirely
right.
A
So
thinking
through
the
client
scenario
like
saying
the
previous
scenario
we
had
where
there
might
be
something
with
200
objects
on
there,
they'd
only
have
to
be
200
signatures
on
the
thing
you
could
be
trying
to
verify
the
signature.
There
might
be
a
single
signature
on
that
image,
but
if
someone
uploaded
200
cat
pictures,
you're
gonna
pull
down
the
Manifest
for
all
200
cat
pictures,
potentially
before
you
get
to
the
signature
manifest.
E
A
So
that
covers
annotations,
but
we're
saying
we
don't
have
annotations,
we
don't
have
the
artifact
type.
So
all
you
get
back
when
you
say
give
me
all
the
refers.
This
image
is
a
list
of
descriptors
and
I'll
say:
is
that
it's
an
artifact
with
this
digest,
doesn't
tell
you
what
kind
of
artifact
it
is,
doesn't
tell
you
any
metadata
on
it.
A
B
I
Think
I
think
that's
basically
exactly
what
I
was
going
to
ask
is
is
sort
of
how,
if
you're,
if
you're,
saying
you're,
having
trouble
understanding
what
it's
for
like
how?
How
do
you
differentiate
a
signature
from
an
s-bomb
if
you're
a
client
that
only
cares
about
one
of
them
or
do
you
think
it
just
doesn't
matter.
F
No
I
mean
like
I,
get
that
in
the
intention
of
that
from
like
these
two
use
cases
right.
It's
like
okay,
this
string
means
this
thing.
This
string
means
the
other
thing,
but
if
you're
writing
a
client
that
doesn't
know
specifically
about
say,
like
notary
V2
as
a
project,
and
you
want
to
do
something
meaningful
with
an
artifact
type
or
even
when
you're
selecting
an
artifact
type.
F
C
C
I
F
Okay,
sure,
but
but
like
that
example
of
like
I,
think
that
would
be
a
bad
change,
but
I
don't
know
like
the
people
coming
up
with
this
field
in
the
first
place
like
oh,
we
should
change
it
to
this.
It's
like
okay,
like
what
my
understanding
of
oh.
This
is
like
an
arbitrary
string
that,
like
you,
choose
as
like
a
match.
It's
basically
a
magic
header
right
for
your
file
type
right,
but
like
it.
E
F
A
Type,
we
we
definitely
have
a
hole
in
terms
of
we
don't
describe
example
usages
and
how
people
should
be
using
it.
So
I
110
with
you
on
that
one
and
I
have
push
for
us
to
standardize
it
more
and
I've
gotten
pushed
back,
saying
No.
It
should
be
done
by
user,
Sonata
or
CI,
and
so
I
I
see
both
sides
of
that
I'll
I'll
play.
A
We
think
are
good
examples
yeah,
but
I
think
there
is
a
difference
between
saying
we
don't
know
what
we
should
send
it
to
and
saying
we
should
get
rid
of
the
field
saying
we
don't
know
what
we
should
set
it
to.
We
can
at
least
defer
that
decision
until
later
on
and
kind
of
figure
out.
Okay,
let's
get
some
standards
around
this
to
say
we
don't
want
the
field
in
there
I
think
we're
opening
ourselves
up
some
challenges,
because
I
I
think
there
are
two
initial
use
cases
we're
going
to
see.
A
One
is
that
there's
going
to
be
clients
pushing
data
that
only
that
one
client
knows
about,
and
they
want
to
be
able
to
filter
on
just
their
one
bit
of
client
data
and
so
they're
going
to
put
that
on
there.
It's
just
the
top
little
filter
of
only
show
me
the
stuff
that
belongs
to
my
clients,
so
that
I
don't
have
to
look
at
anybody
else's
data
and
they
can
kind
of
get
their
own
little
vision
of
this
thing
and
the
other
use
case
out.
A
There
is
going
to
be
when
we
get
into
the
standards,
and
so
once
you
start
pushing
a
standard,
spdxs
bomb,
Cyclone,
DXs
bomb
and
Json
format.
When
you
start
attaching
that
kind
of
stuff
to
an
image,
I
think
there's
going
to
be
a
push
outside
of
just
the
client,
pushing
it
to
be
the
standards
body.
It
needs
to
talk
about
how
they
want
to
push
the
artifact,
so
I
think
we
got
two
tiers
of
how
this
can
be
done,
but
I
think
each
of
them
I
see
some
value
in
happiness
there.
A
I
The
maybe
like
taking
a
step
back
is
the
the
use
case
of
sort
of
differentiate,
differentiating
artifacts
by
the
type
that
they
are
does.
Does
that
make
sense
to
everybody?
I
guess.
Does
that
make
sense
to
you?
John
yeah
I
get
that
okay.
So
we
agree
that,
like
the
functionality
is
important,
is,
is
there
some
like?
Should
we
use
something?
Are
we
saying
we
shouldn't
use
artifact
type
and
instead
we
should
use
some
more
well-defined
enum
or
something.
I
C
I
Yeah
I
think
there
were
two
reasons
why
we
used
this.
We
we
wanted
to
do
something
to
allow
people
to
differentiate
it,
and
then
the
other
part
is
that
artifacts
today,
as
they
exist
in
oci
Registries,
when
they're
pushed
as
image
manifests,
already
use
this
config
media
type
field
to
overload
to
give
clients
some
hint
about
like
what
the
artifact
is,
and
so
that's
already
a
media
type.
I
And
it's
like
already
in
use
by
I'm
sure
you
know
this,
but
like
Helm
and
and
other
other
folks,
and
so
if
this
is,
it
seemed
as
though
this
would
be
the
way
to
sort
of
move
forward
and
solve
that
problem
in
a
way
that,
like
tools,
have
already
kind
of
started,
doing
without
any
advice
from
spec
and
standards.
Folks.
F
I
B
I
wanna,
probably
like
agree
with
what
John
said,
which
is
most
artifacts,
that
we're
probably
gonna
see,
is
only
going
to
have
one
blob,
and
that
is
a
little
bit
of
a
confusion
between
the
blob
and
mini
type.
The
but
I
also
want
to
point
out
that
the
intention
of
the
artifact
type
was
for
filtering.
We
did.
We
had
a
clear
discussion
that
we
can't
hoist
all
annotations
and
filter
by
annotations,
so
we
make
a
like
a
like.
B
But
what
what
is,
what
is
the?
How
can
we
make
forward
and
go
forward
in
such
a
way
that
clients
cannot
get
everything
that
a
subject
refers,
and
so
one
degree
of
filtering
is
what
I
think
the
ask
was
we
don't
want
to
go
full
blown
all
annotations,
I
think
that's,
definitely
not
something
that
we
can
implement,
but
one
pivot.
Besides
the
digest
to
find
out
whether
it's
a
signature,
whether
it's
an
s-bomb,
whether
it's
my
magic
client,
attaching
something
right
so
that
that
was
the
only
ask
from
a
requirement
perspective.
A
A
This
assigning
the
notation
client
can
understand
and
within
that
you
might
have
multiple
different
blob
media
types
or
probably
only
one
per,
but
it
would
say
this
one's
going
to
be
a
JWT,
this
one's
going
to
be
coziest,
and
you
know
some
other
format
of
how
you've
wrapped
the
individual
signature
can
be
on
the
blob
and
so
I
I
think
that
top
level.
One,
though,
was
very
useful
for
the
client
to
know
this
is
some
data
that
I
know
how
to
parse.
A
C
F
I,
probably
something
we
should
have
right
in
the
case
where
maybe
there
isn't
an
artifact
type
in
the
future,
when
we
maybe
we
we
allow
the
refers
API
to
return
things
Beyond,
like
only
the
subject
field,
it
would
be
nice
that
I
guess.
Maybe
this
is
already
a
language
where
like,
if
there's
not
an
artifact
type,
it
doesn't
need
to
be
returned.
A
A
So
I
I
suspect
part
of
the
challenge
that
you're
getting
at
John
is
that
you
want
to
see
this
used
for
other
stuff
and
the
other
stuff
you
want
to
see
it
used
on.
This
just
doesn't
fit
your
use
cases
in
there.
So
if
you
want
to
look
at
what
does
this
plot?
Where
is
this
blob
used
in
all
the
different
places?
What
we've
written
here
doesn't
even
remotely
apply
to
what
you're
thinking
of.
I
A
At
least
for
right
now,
every
artifact
has
the
option
of
having
a
field,
and
every
image
does
have
that
field
and
there's
the
only
two
things
where
we're
able
to
point
to
if,
as
this
was
extended,
Beyond
this
that
changes
but
I
I
think
that's
not
so
much.
A
change
of
what
the
subject
is
used
for
is
a
change
of
what
they
refers
apis
used
for,
and
maybe
it
would
just
make
sense
to
have
a
different
API
than
reverse.
What
you're
thinking
of.
E
A
What
we've
got
right
now
is:
we've
got
the
subject
field.
That
applies
the
refers
API
if
there
was
just
a
different
back
ref
API
that
you
said,
give
me
all
the
back
references
for
this
Digest
and
it
spit
spit
back
out
a
array
of
descriptors.
There
I
think
that
would
fit
what
John's
looking
for
on
his
side
and
it
wouldn't
wouldn't
conflict
with
everything
we've
been
doing
on
the
subject.