Improving usage of reference terminology

[sudo-bmitch]

In the current spec, there are multiple references to <reference> as either a tag or digest. However in the Docker context, that same term means the entire pointer to pull a specific image, e.g. ubuntu:latest or quay.io/prometheus/node-exporter:v1.0.0 or busybox@sha256:4fe8827f51a5e11bb83afa8227cbccb402df840d32c6b633b7ad079bc8144100. Trying to keep straight whether a tag is the whole image name, or just the part after the colon, and knowing if an image name is the repo name or a full reference to a specific image, gets confusing. So I would recommend that the spec define this term at the top and consistently use them throughout the spec.

[sudo-bmitch]

Also, I'm not quite sure where else to put this, and whether it warrants it's own issue in this or another OCI project, since I don't think any of the OCI projects cover the syntax of the client side "reference format", however the docker definition is either ambiguous or possibly incorrect when specifying the regex for the domain.

Docker's comments indicate the registry name can optionally have a . or : in the reference, followed by another domain component or port number respectively. However in the implementation, it's required that at least one of those characters exist to be considered a registry name and not a path component for a repository on Docker Hub. So for example localhost/busybox:latest would try to pull busybox from Docker Hub's localhost user, and not from a registry running on the user's local machine.

Is there somewhere in OCI where we specify these client side reference regex strings, or some equivalent?

[jonjohnsonjr]

I'd throw in <identifier> as a reasonable term for a tag or digest.

[amouat]

This was also source of confusion to me and leaks into issues when writing code (it would be good to have unambiguous definitions).

I note the following text from the bottom of the image spec:

Future versions of this specification may include the following OPTIONAL features:

    Signatures that are based on signing image content address
    Naming that is federated based on DNS and can be delegated

Which suggests to me that these definitions may move spec in the future.

+1 for identifier, but does everything before become repository? Should we have something separate for domain and path?