|
| 1 | +# Abstract |
| 2 | + |
| 3 | +The Docker registry protocol has become the defacto standard across the container registry world ([https://github.com/docker/distribution/blob/master/docs/spec/index.md](https://github.com/docker/distribution/blob/master/docs/spec/index.md)). |
| 4 | + |
| 5 | +In the OCI, having a solid, common distribution specification with conformance testing will ensure long lasting security and interoperability throughout the container ecosystem. |
| 6 | + |
| 7 | +## Proposal |
| 8 | + |
| 9 | +TL;DR; Move [https://github.com/docker/distribution/tree/master/docs/spec](https://github.com/docker/distribution/tree/master/docs/spec) to [https://github.com/opencontainers/distribution-spec](https://github.com/opencontainers/distribution-spec) |
| 10 | + |
| 11 | +This proposal covers the distribution API spec, and while it does not cover the code for the docker-registry, that implementation is considered the reference implementation. There are other implementations of this protocol, not all are open-source though (Google gcr.io, Amazon ECR, CoreOS Quay, Gitlab registry, JFrog Artifactory registry, Huawei Dockyard, etc). |
| 12 | + |
| 13 | +In the past when the topic of having an OCI specification around the distribution of container images, it was deferred as "let’s get the image format defined, mean while the industry will settle on a distribution standard". Fast forward, OCI image format is out and adopted, and the Registry v2 is the defacto standard. There is and will be use-cases for alternate methods and the future will likely hold creative ways to push, fetch and share container images, but right now this promotion serves to acknowledge by the OCI the current industry standard of distributing container images. |
| 14 | + |
| 15 | +There is polish that is needed e.g. broken links to storage-driver docs, as well as making sections more generic regarding the OCI descriptors and media-types, but on the whole this is a lateral move. |
| 16 | + |
| 17 | +## Initial Maintainers |
| 18 | + |
| 19 | +* Stephen Day < [email protected]> ( @stevvooe) |
| 20 | +* Vincent Batts <[email protected]> ( @vbatts) |
| 21 | +* Derek McGowan < [email protected]> ( @dmcgowan) |
| 22 | + |
| 23 | +Additional Maintainers to consider: |
| 24 | + |
| 25 | +* Ahmet Alp Balkan (Google) |
| 26 | +* Matt Moore (Google) |
| 27 | +* Yuwa (MSFT) |
| 28 | +* Clayton Coleman (Red Hat) |
| 29 | +* Antonio Murdaca (@runcom) (Red Hat) |
| 30 | +* Samuel Karp (@samuelkarp) (AWS) |
| 31 | +* Mike Brown (IBM) |
| 32 | +* Jimmy Zelinskie [email protected] ( @jzelinskie) |
| 33 | + |
| 34 | +* Vanessa Sochat (@vsoch) |
| 35 | + |
| 36 | +## Code of Conduct |
| 37 | + |
| 38 | +This project would incorporate (by reference) the OCI Code of Conduct ([https://github.com/opencontainers/tob/blob/master/code-of-conduct.md](https://github.com/opencontainers/tob/blob/master/code-of-conduct.md)). |
| 39 | + |
| 40 | +## Governance and Releases |
| 41 | + |
| 42 | +This project would incorporate the Governance and Releases processes from the OCI project template: [https://github.com/opencontainers/project-template](https://github.com/opencontainers/project-template). |
| 43 | + |
| 44 | +## Project Communications |
| 45 | + |
| 46 | +Both of the proposed projects would continue to use existing channels in use by the OCI developer community for communication including: |
| 47 | + |
| 48 | +* GitHub for issues and pull requests |
| 49 | +* The [email protected] email list |
| 50 | +* The monthly OCI developer community conference call |
| 51 | +* The #OpenContainers freenode IRC channel |
| 52 | + |
| 53 | +## Versioning / Roadmap |
| 54 | + |
| 55 | +The API spec is currently considered v2 and we will start the specification at v2.0. Fewer places to change and compare, and it would keep with it being a lateral move. |
| 56 | + |
| 57 | +## Frequently Asked Questions (FAQ) |
| 58 | + |
| 59 | +* Does this include the code of the docker-registry? |
| 60 | + * No. This is an API specification discussion. |
| 61 | + |
0 commit comments