Steve Lasker

definitely a +1 for annotation support, as this will hopefully start priming the pump for others to annotate, then we can start the search apis: https://stevelasker.blog/2019/08/25/oci-artifacts-and-a-view-of-the-future/ Only minor change might...

I was on the fence for a while as I was hopeful https://github.com/opencontainers/artifacts/pull/37 would be the "one manifest to rule them all". With the latest conversations, you've helped with on...

> On a side-note, I noticed that the vnd.oci.image.manifest.v1+json was registered, but other mediatypes, including media-types for image layers are not; should they be? > This is being worked on...

Adding new compression formats to a specific type is goodness to bring that artifact forward with new capabilities. Providing consistent behavior across an ecosystem of successful deployment of multiple versions...

Same comment on #780: should this be in the spec, or up to each registry operator to specify?

Hi @ValentinViennot, Great scenario, and something that's been a hot topic around when an artifact should be considered EOL, and what actions should be taken. The interesting part is when...

> Vendor support, as proposed here, feels like a commitment to me and should never be shortened. I tend to agree that "support shouldn't be shortened", unless an exploit makes...

Is this something the spec should limit, or something each registry would specify? We each have layer count and size constraints. We have different repo counts. Some of these are...

This is largely a dupe of the `oci.artifact.manifest` proposal. The main difference here is the `references` property is placed on a descriptor, as opposed to being in the manifest. Contemplating...

If you're asking for a standard for how different compression formats should be applied to layers, regardless of type. That sounds like greatness. And, yes, I would really like to...