Annotations should be optional, not automatically added.

[SteveLasker]

When using the ORAS binary, it automatically adds several annotations. This was intended to be representative of what's possible, however as we consider adding to OCI as a standard library, there's valid concern that this implies a standard, as opposed to an ability.
Some of the annotations are in the "interesting" meta-data category, while others are used to determine how/where to extract compressed content. Such as a directory of files passed in.
This issue is to track removal of annotations without explicitly asking for them, and finding an alternative means for the file compression/decompression of files. Perhaps using the config object.

oras push localhost:5000/hello-artifact:v2 \
  --manifest-config config.json:application/vnd.acme.rocket.config.v1+json \
  artifact.txt:text/plain \
  ./docs/:application/vnd.acme.rocket.docs.layer.v1+tar

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.acme.rocket.config.v1+json",
    "digest": "sha256:7aa5d0dee9a3a73c81db4356cf7aa5666e175d96e68ee763eeb977bd7ba59ee5",
    "size": 20
  },
  "layers": [
    {
      "mediaType": "text/plain",
      "digest": "sha256:a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447",
      "size": 12,
      "annotations": {
        "org.opencontainers.image.title": "artifact.txt"
      }
    },
    {
      "mediaType": "application/vnd.acme.rocket.docs.layer.v1+tar",
      "digest": "sha256:20ae7d51e2365405e6942439140d897548e1d4610db60354aef8a5ce1f1699a7",
      "size": 196,
      "annotations": {
        "io.deis.oras.content.digest": "sha256:4329ea6c620ca4e9cedc5f5e8040432114cb5d64fc53107ea870db149e3d2b9e",
        "io.deis.oras.content.unpack": "true",
        "org.opencontainers.image.title": "docs"
      }
    }
  ]
}

[SteveLasker]

Reviewing the tar docs, it's not clear why we need the layer annotations.

When the oras binary is used, can we be smarter about the extension used on the layer.mediaType? In the example below, since "mediaType": "application/vnd.acme.rocket.docs.layer.v1+tar" is tar, we could simply untar it in the root of the directory oras is executed within. if "mediaType": "application/vnd.acme.rocket.docs.layer.v1+tar+gzip" we untar and decompress.

{
      "mediaType": "application/vnd.acme.rocket.docs.layer.v1+tar",
      "digest": "sha256:20ae7d51e2365405e6942439140d897548e1d4610db60354aef8a5ce1f1699a7",
      "size": 196,
      "annotations": {
        "io.deis.oras.content.digest": "sha256:4329ea6c620ca4e9cedc5f5e8040432114cb5d64fc53107ea870db149e3d2b9e",
        "io.deis.oras.content.unpack": "true",
        "org.opencontainers.image.title": "docs"
      }
    }

[SteveLasker]

Looks like the annotations are used to persist individual files, not tars.
For the ORAS binary, what if we always tar files, so the metadata for the filename is persisted in the tar?

[jdolitsky]

I think that the original purpose of using org.opencontainers.image.title is so that oras knows the name of the files to place onto the filesystem based on layers retrieved on pull.

When using the ORAS binary, it automatically adds several annotations

I believe this is incorrect, just one annotation, org.opencontainers.image.title. I'm unfamilair with the other ones used on tarring a directory, I'm not sure why these are need. cc @shizhMSFT

I agree that these should not be automatically added when using as a Go library, however it is already achievable using oras.WithNameValidation(nil). As it relates to the binary, I think the annotation is a requirement and I don't particularly see any issue with that. If it's something we need to bake into the distribution spec, then lets address it.

[SteveLasker]

Closing as this new issue tracks the larger set of issues.