Is <name> URL encoded?

[Moosemorals]

If a name contains a '/', should a registry expect it to be url (percent) encoded on the wire?

e.g, for name 'example/test'

/v2/example/test/tags/list or /v2/example%2ftest/tags/list

[vbatts]

/ is not valid in a name. The paths in the API do allow for nested names (i.e. not just /), despite most registries not supporting this since the docker hub did not support it.

[Moosemorals]

'/' is valid in a name:

<name> refers to the namespace of the repository. [...] Throughout this document, <name> MUST match the following regular expression: [a-z0-9]+([._-][a-z0-9]+)*(/[a-z0-9]+([._-][a-z0-9]+)*)*

(Notice the / at the start of the capture group after the first *)

so example/test is a valid name.

My problem is that the spec isn't clear if <name> in a URL should be escaped or not.

[robberphex]

Is a/b/c a valid name?

Currently, there is no registry support 3 or more level name, just two levels <user>/<projectName>.

Is supporting 3 or more level name a good idea?

[mikebrow]

We should probably discuss this in the faq..

Is a/b/c a valid name?

Per the regular expression for <name> a/b/c is valid, yes.

Currently, there is no registry support 3 or more level name, just two levels <user>/<projectName>.

Many, but not all, container registries limit the depth to one. The distribution specification, as currently written, does not specify requirements with respect to how many levels deep or what the levels mean. That exercise, to define namespace requirements, was left for a future revision to tackle.

Is supporting 3 or more level name a good idea?

Define supporting. Registry, Mirror, Client tool, user? For a client, I would suggest allowing the user to use what they want to enter, and check for errors if any from the registry selected. For a registry/mirror, whether they define some namespacing system or use the first and possibly only level of the path as the account login name, that's up to them. At this point, the distribution spec is not specifying details around authentication or namespacing. I hope we can get to those issues in the next major release.

Cheers, Mike

[Moosemorals]

In terms of my original question then, name is not url encoded and my (toy) registry can say "no slashes" and expect clients to cope.

(Closing because I've got a useful answer)

Out of interest, where's work on the next version of the spec being done?

[samuelkarp]

Currently, there is no registry support 3 or more level name, just two levels /.

Many, but not all, container registries limit the depth to one.

For what it's worth, Amazon ECR does not limit the depth to one; you can create a repository named foo/bar/baz if you want.

[mikebrow]

Out of interest, where's work on the next version of the spec being done?

great question and broad question that is hard to answer

Some portions of the potential next version are still undergoing innovation and debate. Note the OCI Mission Statement:

The Open Container Initiative provides an open source technical community
 within which industry participants may easily contribute to building
 vendor-neutral, portable and open specifications, reference implementations,
 and tools that deliver on the promise of containers as a source of application
 portability backed by a certification program.

The Open Container Initiative does not seek to be a marketing organization,
 define a full stack or solution requirements, and will strive to avoid 
 standardizing technical areas undergoing innovation and debate.

Other portions are arguably somewhat settled. The more settled parts, I expect, will be specified here in opencontainers/