Brandon Mitchell

> This being said, I suggest to focus on wrapping up on #494, which is supposed to define the API, and not on SHA256 vs SHA512 vs BLAKE3. I believe...

> > Rewriting the conformance tests is non-trivial, and I'm chipping away at it in my spare time. > > Your [initial description here](https://github.com/opencontainers/distribution-spec/pull/543#issue-2365090729) includes "Redesign conformance tests in a...

> > Working through some of the other co-dependent issues would be much more helpful. A couple of important ones are... > > Hmm, I'm not clear on how either...

> The idea is good. Basically from the image spec perspective it's the same as compatibility field idea (the same field just different name). They feel very different to me...

Distribution and distribution-spec are separate projects. There's a lot of overlap in the terms, but also inconsistent usage between the two. The concept of a reference from the distribution project...

Closing this one for now because we don't define a [reference](https://github.com/distribution/reference/) in OCI, yet.

My understanding is the last `` value is the one always used for the next request, and registries will reject the usage of older values. It's certainly worth clarifying.

I wouldn't say things are too late to change. See #366 that was adding this recently. Chunked uploads aren't well supported, the docker engine uses them with a single large...

@NickLarsenNZ are there existing registries that push (not pull) directly to an external S3 store today? If so, how does the registry verify the digest of the pushed blob? And...

Redefining the spec to require new functionality for clients to work would break all existing clients and is something we try very hard to avoid. The spec is typically a...