Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify repository vs registry terminology #325

Merged
merged 1 commit into from
Jul 18, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,7 @@ These error codes are OPTIONAL and clients SHOULD NOT depend on them.
Several terms are used frequently in this document and warrant basic definitions:

- **Registry**: a service that handles the required APIs defined in this specification
- **Repository**: a scope for API calls on a registry for a collection of content (including manifests, blobs, and tags).
- **Client**: a tool that communicates with Registries
- **Push**: the act of uploading blobs and manifests to a registry
- **Pull**: the act of downloading blobs and manifests from a registry
Expand Down Expand Up @@ -175,7 +176,7 @@ If the digest does differ, it MAY be the case that the hashing algorithms used d
See [Content Digests](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md#digests) <sup>[apdx-3](#appendix)</sup> for information on how to detect the hashing algorithm in use.
Most clients MAY ignore the value, but if it is used, the client MUST verify the value against the uploaded blob data.

If the manifest is not found in the registry, the response code MUST be `404 Not Found`.
If the manifest is not found in the repository, the response code MUST be `404 Not Found`.
Copy link
Member

@mikebrow mikebrow May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

repository is optional here...

maybe registry, or repository if restricted to a repository in the registry,

wouldn't say it each time though just this once?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these "in the registry" statements could almost just be removed. I agree it is up to the implementation to determine the scope of a blob or manifest. Repository scope makes the most sense but that might need more explanation above or as part of the implementation guide.


##### Pulling blobs

Expand All @@ -188,7 +189,7 @@ A GET request to an existing blob URL MUST provide the expected blob, with a res
A successful response SHOULD contain the digest of the uploaded blob in the header `Docker-Content-Digest`.
If present, the value of this header MUST be a digest matching that of the response body.

If the blob is not found in the registry, the response code MUST be `404 Not Found`.
If the blob is not found in the repository, the response code MUST be `404 Not Found`.

A registry SHOULD support the `Range` request header in accordance with [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests).

Expand All @@ -204,7 +205,7 @@ A HEAD request to an existing blob or manifest URL MUST return `200 OK`.
A successful response SHOULD contain the digest of the uploaded blob in the header `Docker-Content-Digest`.
A successful response SHOULD contain the size in bytes of the uploaded blob in the header `Content-Length`.

If the blob or manifest is not found in the registry, the response code MUST be `404 Not Found`.
If the blob or manifest is not found in the repository, the response code MUST be `404 Not Found`.

#### Push

Expand Down
Loading