|
1 | 1 | # Abstract
|
2 | 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/api.md](https://github.com/docker/distribution/blob/master/docs/spec/api.md)). |
| 3 | +The Docker registry protocol has become the defacto standard across the container registry world. |
4 | 4 |
|
5 | 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 | 6 |
|
7 | 7 | ## Proposal
|
8 | 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) |
| 9 | +TL;DR; Move [`api.md`][api.md] to a new [distribution-spec project](https://github.com/opencontainers/distribution-spec). |
10 | 10 |
|
11 | 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 | 12 |
|
13 | 13 | In the past when the topic of having an OCI specification around the distribution of container images was discussed, it was deferred as "let’s get the image format defined, meanwhile 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 | 14 |
|
15 | 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 | 16 |
|
| 17 | +This project is scoped to cover the client ↔ registry interaction. The following are out of scope: |
| 18 | + |
| 19 | +* Authentication and authorization. Docker's current registry uses an [extension][token] of the [`Bearer`][rfc6750] [auth scheme][rfc7235-s2.1]. Work on specifying Docker's scheme will continue independently, and is orthogonal to the registry API. |
| 20 | +* Signing images. All resources are content-addressable and can be signed in external systems. |
| 21 | +* Discovering images. Discovery and registry protocols are completely separate and do not need to be added together. |
| 22 | + |
17 | 23 | ## Initial Maintainers
|
18 | 24 |
|
19 | 25 | * Stephen Day < [email protected]> ( @stevvooe)
|
@@ -64,3 +70,8 @@ The API spec is currently considered v2 and we will start the specification at v
|
64 | 70 |
|
65 | 71 | * Simplifies tag listing: docker/distribution#2169
|
66 | 72 | * Allows listing of manifests: docker/distribution#2199
|
| 73 | + |
| 74 | +[api.md]: https://github.com/docker/distribution/blob/cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/api.md |
| 75 | +[token]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/token.md |
| 76 | +[rfc6750]: https://tools.ietf.org/html/rfc6750 |
| 77 | +[rfc7235-s2.1]: https://tools.ietf.org/html/rfc7235#section-2.1 |
0 commit comments