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

image manifest: support use as artifact #1030

Merged
merged 2 commits into from
Jun 15, 2023
Merged
Show file tree
Hide file tree
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
2 changes: 1 addition & 1 deletion config.md
Original file line number Diff line number Diff line change
Expand Up @@ -248,7 +248,7 @@ Note: Any OPTIONAL field MAY also be set to null, which is equivalent to being a
This field is used to mark if the history item created a filesystem diff.
It is set to true if this history item doesn't correspond to an actual layer in the rootfs section (for example, Dockerfile's [ENV](https://docs.docker.com/engine/reference/builder/#/env) command results in no change to the filesystem).

Any extra fields in the Image JSON struct are considered implementation specific and MUST be ignored by any implementations which are unable to interpret them.
Any extra fields in the Image JSON struct are considered implementation specific and MUST NOT generate an error by any implementations which are unable to interpret them.
Copy link
Member

Choose a reason for hiding this comment

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

👍 This has been a confusing line


Whitespace is OPTIONAL and implementations MAY have compact JSON with no whitespace.

Expand Down
9 changes: 7 additions & 2 deletions considerations.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,12 @@
# Extensibility

Implementations that are reading/processing [manifests](manifest.md) or [image indexes](image-index.md) MUST NOT generate an error if they encounter an unknown property.
Instead they MUST ignore unknown properties.
Implementations storing or copying content MUST NOT modify or alter the content in a way that would change the digest of the content. Examples of these implementations include:
Copy link
Member

Choose a reason for hiding this comment

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

While I agree with this sentence regarding altering of content, it could be straying away from the topic whether to generate errors or not

Copy link
Member

Choose a reason for hiding this comment

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

Agreed, this feels like a distribution-spec concern, not an image-spec concern -- a registry that intentionally modifies content pushed to it has some interesting potential use cases, and wouldn't be compliant to the distribution spec, but absolutely could be image-spec complaint, and that would be OK, I think?

* A [registry implementing the distribution specification](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#definitions), including local registries, caching proxies
* An application which copies content to disk or between registries

Implementations processing content SHOULD NOT generate an error if they encounter an unknown property in a known media type. Examples of these implementations include:
* A [runtime implementing the runtime specification](https://github.com/opencontainers/runtime-spec/blob/main/spec.md)
* An implementation using OCI to retrieve and utilize artifacts, e.g.: a WASM runtime

# Canonicalization

Expand Down
2 changes: 1 addition & 1 deletion image-index.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ For the media type(s) that this document is compatible with, see the [matrix][ma

Image indexes concerned with portability SHOULD use one of the above media types.
Future versions of the spec MAY use a different mediatype (i.e. a new versioned format).
An encountered `mediaType` that is unknown to the implementation MUST be ignored.
An encountered `mediaType` that is unknown to the implementation MUST NOT generate an error.

- **`platform`** *object*

Expand Down
2 changes: 1 addition & 1 deletion image-layout.md
Original file line number Diff line number Diff line change
Expand Up @@ -147,7 +147,7 @@ This index provides an established path (`/index.json`) to have an entry point f
* No semantic restriction is given for the "org.opencontainers.image.ref.name" annotation of descriptors.
* In general the `mediaType` of each [descriptor][descriptors] object in the `manifests` field will be either `application/vnd.oci.image.index.v1+json` or `application/vnd.oci.image.manifest.v1+json`.
* Future versions of the spec MAY use a different mediatype (i.e. a new versioned format).
* An encountered `mediaType` that is unknown SHOULD be safely ignored.
* An encountered `mediaType` that is unknown MUST NOT generate an error.


**Implementor's Note:**
Expand Down
8 changes: 7 additions & 1 deletion manifest.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ Unlike the [image index](image-index.md), which contains information about a set
This OPTIONAL property contains the type of an artifact when the manifest is used for an artifact.
This MUST be set when `config.mediaType` is set to the [scratch value](#example-of-a-scratch-config-or-layer-descriptor).
If defined, the value MUST comply with [RFC 6838][rfc6838], including the [naming requirements in its section 4.2][rfc6838-s4.2], and MAY be registered with [IANA][iana].
Implementations storing or copying image manifests MUST NOT error on encountering an `artifactType` that is unknown to the implementation.

- **`config`** *[descriptor](descriptor.md)*

Expand All @@ -40,6 +41,11 @@ Unlike the [image index](image-index.md), which contains information about a set
- **`mediaType`** *string*

This [descriptor property](descriptor.md#properties) has additional restrictions for `config`.

Implementations MUST NOT attempt to parse the referenced content if this media type is unknown and instead consider the referenced content as arbitrary binary data (e.g.: as `application/octet-stream`).

Implementations storing or copying image manifests MUST NOT error on encountering a value that is unknown to the implementation.

Implementations MUST support at least the following media types:

- [`application/vnd.oci.image.config.v1+json`](config.md)
Expand Down Expand Up @@ -83,7 +89,7 @@ Unlike the [image index](image-index.md), which contains information about a set
- [`application/vnd.oci.image.layer.nondistributable.v1.tar+gzip`](layer.md#gzip-media-types)

Manifests concerned with portability SHOULD use one of the above media types.
An encountered `mediaType` that is unknown to the implementation MUST be ignored.
Implementations storing or copying image manifests MUST NOT error on encountering a `mediaType` that is unknown to the implementation.

Entries in this field will frequently use the `+gzip` types.

Expand Down