OCI Artifact manifest specification support

[termoshtt]

Motivation

OCI Artifact manifest specifiaction will be introduced in OCI image spec v1.1.0 (currently rc2) with referrer API in OCI distribution spec in order to store non-image artifacts, e.g. helm chart or SBOM (Software Bill Of Materials) by sigstore/cosign into OCI registry.

Rationale and alternatives

There are two artifact manifest specifications:

• OCI Artifact manifest application/vnd.oci.artifact.manifest.v1+json definition by OCI image spec
  • This is still in draft, introduced in OCI image spec 1.1.0-rc1
  • Announcing Docker Hub OCI Artifacts Support
• ORAS Artifact manifest application/vnd.cncf.oras.artifact.manifest.v1+json by oras-project/artifact-spec
  • This is experimentally supported by Azure container registry

As far as I studied (termoshtt/ocipkg#78), ORAS project has started specifying the artifact manifest, and created own manifest "ORAS Artifact manifest" as pre-draft for submitting to OCI. It has been submitted to OCI as "OCI Artifact manifest" with some fixes, and merged to OCI image spec at 1.1.0-rc1.

Unresolved questions

IANA media type

Because OCI Artifact stores several types of artifact, it stores the media type of its artifact, e.g. application/gzip when storing *.gz file. About this media type slot, OCI Artifact manifest specification says:

https://github.com/opencontainers/image-spec/blob/main/artifact.md

This property SHOULD be used and contain the mediaType of the referenced artifact. If defined, the value MUST comply with RFC 6838, including the naming requirements in its section 4.2, and MAY be registered with IANA.

The media types registered by IANA (Internet Assigned Numbers Authority) is listed in https://www.iana.org/assignments/media-types/media-types.xhtml . I guess it will be updated frequently (last update is 2022-11-10). Since the media type always can be represented by a String and be managed by oci_spec::MediaType::Other, however, I hope this also be statically typed. I experimentally created iana-media-types crate which translate the media type list in IANA into Rust code automatically. I am planning to re-generate this crate using GitHub Actions as upstream IANA definition upgrades.

So my question is

• Using iana-media-types crate is acceptable in terms of managing oci_spec crate?

I willing to integrate iana-media-types crate into this repository, or transfer current repository.