Define image name format string.

[sgotti]

The image name format string is used inside appc/spec/discovery and also at least by rkt. Do you think it should be part of and defined in appc/spec? If not, the related coded should probably be moved outside.

By now it's something like this

name[,label1=value][,label2=value],...
or
name:version[,label1=value][,label2=value]

where name type is ACIdentifier, label type is ACIdentifier and label value is string.

A doubt:
Does name have to absolutely contain a domain part (for example coreos.com/etcd)? If not meta discovery will probably fail as there's not domain to ask to.

At the same time, actually docker2aci creates images from the default docker repository with names like busybox:latest.

[sgotti]

Does name have to absolutely contain a domain part (for example coreos.com/etcd)? If not meta discovery will probably fail as there's not domain to ask to.

Partially answering to myself: the spec/aci.md says: name (string, required) [...] This is not expected to be unique (see the version label) but SHOULD have a URL-like structure to facilitate App Container Image Discovery. [...]

Since the definition of name in the image name string should be the same of the name in the image manifest looks like it's not mandatory.

[iaguis]

As a side note we could change docker2aci so it generates index.docker.io/busybox:latest and it's not a special case.

[sgotti]

Few additional thoughts:

• A possible parsing problem of that format can be caused by labels values containing a comma , (as label's values are define of string type). One solution will be to require commas to be escaped (in a ways to define).
• Additionally should the format use the URL escaping rules? The actual parsing function https://github.com/appc/spec/blob/master/discovery/parse.go#L49 uses url.Parse requiring the contents to be url escaped. See for example https://github.com/coreos/rkt/blob/master/rkt/stage1hash.go#L119 that needs to escape the version because the git version contain a +.

[iaguis]

Related #514

[jonboulle]

I think we should probably just bite the bullet and put this somewhere in the spec but I'm not sure where. It's kind of an extra/suggestion. @sgotti any ideas?

[jonboulle]

also #520

[sgotti]

@jonboulle mmm. Given that it's not a foundamental part of the spec but it's coded inside the reference go implementation and used by rkt and probably other future project perhaps something in an "extra" directory like suggested by you sounds good.

About the actual format another unresolved problem is the clash with other schemeless formats like filenames: rkt/rkt#715