Discussion: Media types for bundles in OCI registries

[radu-matei]

@jlegrone's original comment:

Nit/question: is application/vnd.cnab.bundle.config.v1+json redundant? We've been using application/vnd.cnab.config.v1+json internally. I can see the former being nice if we add more cnab-scoped artifact types in the future though.

@carolynvs wrote:

is application/vnd.oci.image.config.v1+json an example or the only allowed alternate type? If the docker image type would be allowed as well, I suggest changing this to "(e.g. application/vnd.oci.image.config.v1+json)" to allow room for other values.

[chris-crone]

Picking this up so that we can finalize the registry spec.

@radu-matei @jlegrone: For the bundle media type, I don't have strong opinions but we are using application/vnd.cnab.config.v1+json in CNAB to OCI. Are there other configs we imagine we may need in the future?

@carolynvs: Full paragraph so that those reading have full context:

The bundle.json MUST be serialized as canonical JSON and MUST be stored in the registry as a blob. This blob MUST be referenced by its digest in an OCI manifest. The manifest media type SHOULD be application/vnd.cnab.bundle.config.v1+json but MAY be a standard container image config type (application/vnd.oci.image.config.v1+json) if the target registry does not support the CNAB media type.

I agree that we should make this less strict and accept Docker types. This allows better registry compatibility and avoids us mixing Docker (for the container images) and OCI types (for the bundle manifest and index) which some registries reject.

My suggested change:

This blob SHOULD be referenced by its digest in an OCI manifest but MAY be referenced in a Docker manifest. The manifest media type SHOULD be application/vnd.cnab.bundle.config.v1+json but MAY be a standard OCI container image config type (application/vnd.oci.image.config.v1+json) or Docker container image config type (application/vnd.docker.distribution.manifest.v1+json) if the target registry does not support the CNAB or OCI media types.

[SteveLasker]

Hi folks, Per the OCI Artifact spec for Defining a Unique Artifact Type

The following config.mediaType format is used to differentiate the type of artifact: [registration-tree].[org|company|entity].[objectType].[optional-subType].config.[version]+[optional-configFormat]

What org will CNAB be under? It could be under deislabs I suppose.

Also note the IANA registration process:

New artifact types SHOULD register their unique config.mediaType and unique layer.mediaType with IANA to assure ownership of the type. [Well-known][def-well-known-types] types MUST register their unique mediaTypes to be published for registry consumption.

We're also working on a better collection model, as CNABs really don't fit will int OCI Index. See here for a third manifest type we're proposing. In the meantime, the index mediaType is the best bet. Using the .v1 to v2 versioning will help with any migration in the future.

As for chicken/egg, with the exception of Docker Hub, all major registries now support OCI Artifacts. It's only recently they most started supporting index. It would be great if Docker could simply release the mediaType constraint as we've already seen, customers are placing everything in Docker Hub from VMs to dog/cat pictures by just masking them as a docker mediaType.

[technosophos]

The org is cnab.io, which is correlated to Linux Foundation.

[SteveLasker]

@technosophos, the uniqueness is a challenge. We're trying to help other artifact owners understand the pattern and follow the leads of others. Unfortunately, just calling it application/vnd.cnab.bundle.* implies cnab is somehow globally unique. Do you mind following up with the IANA process to claim this mediaType so you could claim you have taken ownership of this mediaType?

For the larger reference manifest problem, we have some new work coming out in the next few weeks. Here's an early preview: https://github.com/SteveLasker/artifacts/blob/artifact-manifest/artifact-manifest/artifact-manifest.md