@opencontainers/distribution-spec-maintainers PTAL
@josephschorr I would imagine the pub-sub to be under extensions here
@justincormack @jonjohnsonjr I would imagine a signature extension here, so that a signature payload on a digest could be pushed to a registry, then the signature extension allows discovering the digests of signatures associated

from a discussion that @dmcgowan and I had today.

While I thought that all the endpoints of any given extension would be sandboxed in its prefix, Derek points out how that could make the ACLs a bit too tricky, without wholly expecting an extension to copy API patterns.

So we walked through both.
We used the notary v2 use-case as our first concrete example.

Notes below (copied from https://hackmd.io/Ljkrt0LORmeVznREeGOWuQ):

GET /v2/_ext/

{
  "0" : {},
  "sigs": {"doc":"http://github.com/opencontainers/distribution-spec/trees/master/ext/ext-sigs.md"}
}

/v2/_ext/sigs/   (reserved for sigs extension)

GET /v2/_ext/sigs/<hash>/<digest>/<name>
POST /v2/_ext/sigs/<hash>/<digest>/<name>
DELETE /v2/_ext/sigs/<hash>/<digest>/<id>

GET /v2/<repo name>/sigs/<hash>/<digest>
POST /v2/<repo name>/sigs/<hash>/<digest>
PUT /v2/<repo name>/sigs/<hash>/<digest>/<hash>/<digest>
DELETE /v2/<repo name>/sigs/<hash>/<digest>/<hash>/<digest>
                            |<--signed---->|<--signature-->|       

{
  "0": {
    "mediaType":"...signature...blob",
    "size": 100,
    "digest": "sha256:deadbeef"
  }
}

What ever mediaType of the signature object itself should be parseable to reference the digest of the blob that it is a signature for. (for garbage collection)

@vbatts The concern I have there is overlap: if I currently have a registry that supports multiple levels of nesting, and I have a repository named mynamespace/arepo/sigs (for whatever reason), now I have a conflict on the paths. Does that means I get the repository responses back, or do I get the sigs for mynamespace/arepo (it might exist on its own, afterall). A similar problem does exist today, but its currently limited in the API, where moving forward this wouldn't be the case.

Perhaps all extensions under the existing API should be prefixed with a character not supported by the current repo names? Like... GET /v2/<repo name>/_/sigs/<hash>/<digest>?

@josephschorr when the API was originally being designed a similar issue also came up with tags, hence the odd tags/list endpoint for listing tags. It may have been a limitation of the handlers we were using at the time, but there was always two parts matched at the end to get around the ambiguity (@stevvooe for more context). I kind of like the idea of differentiating with a "_", maybe "_sigs" is enough. As long as we apply the rule consistently for new endpoints.

Why not just adopt something like the .well_known and let the servers define their own URL prefixes and try and stay as much out of their way as possible? Imposing versioning and all of this other stuff in the URL seems pretty non-ideal.

@jzelinskie I'm highly concerned about overlap: its guaranteed that registries, today, have /v2/... reserved for registry use. If we allow extensions to place themselves wherever they please at the top level, we will likely quickly run into conflicts with existing per-implementation endpoints. .well-known is a good idea, but it should ideally be discoverable as part of the existing OCI endpoints.

For new extensions that are being proposed, but have not yet been accepted into the spec, do we want to set a standard for naming that distinguishes a proposed-extension from a standard-extension? I'm thinking along the lines of vendor prefixes for CSS; this could allow a registry operator to experiment and provide an endpoint for a feature where there isn't yet consensus in the community.

What will this extension covers? Everything in the brainstorm?

scope of the extensions:

 extensions are meant as a way to extend on the generic basic workflows available in the distribution-spec

A way to have a handshake between client-server for additional features capable. e.g. search, signatures, discoverability. etc

The hope of having a server expose which features it implements vs. a newer version (i.e. /v2/) that implements new features, in synchrony.
It's okay to add a batch of OPTIONAL features to the spec, with language around "if you use this OPTIONAL http endpoint then you MUST use the corresponding ones".

I'm really wondering whether this is even the correct approach.

If these features are the right and good for distribution-spec (the API), then just put them in the spec and rev the version.

(Having a call with @dmcgowan @jzelinskie @mikebrow @jdolitsky @vbatts)

This basically needs community discussion around "how can i experiment with bringing in new features, or have my own bespoke feature"

What was the consensus here?
At the root:
/v2/_ext/oci-artifacts/v1/{namespace}/repo/manifests/{digest}/links
or, at the repo
/v2/{namespace}/repo/manifests/{digest}/_ext/oci-artifacts/v1/links

Basically, should _ext/ be a reserved extension anywhere in the uri?

@vbatts, @dmcgowan, @justincormack, in today's OCI weekly call, we discussed moving forward with #111 where we document v2/_ext/ as a reserved namespace for extensions. The question was then: should we use numbered items, and let people fight for reserving a number while they develop and hopefully ship their extension. Or, named elements that have no order. Just uniqueness.

now that 1.0 is tagged, and a number of conversations that touched on this proposal have progressed, I intend to dust this off and find the path forward.

Thanks @vbatts, here's a prototypical example for the reference types: opencontainers/artifacts#29
A direct link to the referrers API

updated PTAL

@opencontainers/distribution-spec-maintainers PTAL

👏