New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distribution Specification #34

Closed
caniszczyk opened this Issue Dec 9, 2017 · 11 comments

Comments

Projects
None yet
4 participants
@caniszczyk
Contributor

caniszczyk commented Dec 9, 2017

At the OCI F2F (https://docs.google.com/document/d/1rL4wiY6Q7R199wz0PBtbbPVjMo_3v2BpO6c1kItPTLw/edit), we discussed kicking off a distribution specification project, based on the Docker distribution spec: https://twitter.com/chanezon/status/938845534466596864

We will have to go through the official OCI channels, which involves a project proposal to the @opencontainers/tob.

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk
Contributor

caniszczyk commented Dec 9, 2017

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 9, 2017

Contributor
Contributor

wking commented Dec 9, 2017

@dmcgowan

This comment has been minimized.

Show comment
Hide comment
@dmcgowan

dmcgowan Dec 10, 2017

Member

From the F2F, it sounds like @vbatts wants to focus on the registry, and continue to
punt on discovery?

@wking the conversation was around standardizing the registry protocol since it already the defacto standard and avoid using the standardization process for innovating on new protocols. Innovation on discovery can handle in tandem to standardization of the registry protocol and added later. My point was that discovery and registry are completely separate and do not need to be added together. Also keep in mind that while all existing clients today are using the registry protocol, there is no common way in which discovery is being done. In this case discovery should not require any changes to the existing registry protocol or implementations.

Member

dmcgowan commented Dec 10, 2017

From the F2F, it sounds like @vbatts wants to focus on the registry, and continue to
punt on discovery?

@wking the conversation was around standardizing the registry protocol since it already the defacto standard and avoid using the standardization process for innovating on new protocols. Innovation on discovery can handle in tandem to standardization of the registry protocol and added later. My point was that discovery and registry are completely separate and do not need to be added together. Also keep in mind that while all existing clients today are using the registry protocol, there is no common way in which discovery is being done. In this case discovery should not require any changes to the existing registry protocol or implementations.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Dec 10, 2017

Contributor

@wking the conversation was around standardizing the registry protocol since it already the defacto standard and avoid using the standardization process for innovating on new protocols.

That makes sense. The risk with specifying after getting widespread adoption is that you can't fix things anymore because the backward-compat cost is too high (like this and opencontainers/image-spec#24). And the risk with specifying before widespread adoption is that you don't know what needs fixing. Either way, the solution is to eventually cut a v2 spec, and that's fine.

Contributor

wking commented Dec 10, 2017

@wking the conversation was around standardizing the registry protocol since it already the defacto standard and avoid using the standardization process for innovating on new protocols.

That makes sense. The risk with specifying after getting widespread adoption is that you can't fix things anymore because the backward-compat cost is too high (like this and opencontainers/image-spec#24). And the risk with specifying before widespread adoption is that you don't know what needs fixing. Either way, the solution is to eventually cut a v2 spec, and that's fine.

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jan 5, 2018

Contributor

As a heads up @opencontainers/tob, here's a draft proposal for the distribution spec project: https://docs.google.com/document/d/15y0SBrrDFIEM7pnU-Oe3Y6pq-eTZfo0mk-k33cS2hR4/edit#heading=h.fs1oc6z7su0d

We will let it simmer for a week or so to gather feedback before formalizing things on GitHub.

Contributor

caniszczyk commented Jan 5, 2018

As a heads up @opencontainers/tob, here's a draft proposal for the distribution spec project: https://docs.google.com/document/d/15y0SBrrDFIEM7pnU-Oe3Y6pq-eTZfo0mk-k33cS2hR4/edit#heading=h.fs1oc6z7su0d

We will let it simmer for a week or so to gather feedback before formalizing things on GitHub.

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jan 10, 2018

Contributor

minutes from the last OCI Dev meeting regarding the distribution spec: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2018/opencontainers.2018-01-10-22.01.html

The plan is to work together on a proposal and present it to the TOB for vote, current thinking is that it won't be ready until after the TOB election on Jan 29th.

Contributor

caniszczyk commented Jan 10, 2018

minutes from the last OCI Dev meeting regarding the distribution spec: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2018/opencontainers.2018-01-10-22.01.html

The plan is to work together on a proposal and present it to the TOB for vote, current thinking is that it won't be ready until after the TOB election on Jan 29th.

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Jan 23, 2018

Contributor

The google doc has been open long enough and seems baked. I converted it to markdown and opened up a PR so we can continue/finalize the discussion there for a couple of weeks or so and than formalize a vote after the new @opencontainers/tob is formed: #35

Contributor

caniszczyk commented Jan 23, 2018

The google doc has been open long enough and seems baked. I converted it to markdown and opened up a PR so we can continue/finalize the discussion there for a couple of weeks or so and than formalize a vote after the new @opencontainers/tob is formed: #35

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 26, 2018

distribution: Also move the Bearer token and OAuth docs
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  So folks writing a client that will interact
with a Docker registry that uses that auth approach will need a
"Docker registry's 'Bearer' additions" spec to follow.  While I prefer
off-the-shelf RFCs for HTTP auth, the Docker registry additions are
small enough, and widely used.  This change adds the client side of
their specification to the new distribution-spec project.

The docker/distribution repository also includes docs for scope [3]
and the JWT token semantics [4].  The scope docs are borderline useful
for clients, but I've left them out because clients can extract the
required scope from WWW-Authenticate in 401ed responses:

  $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1
  HTTP/1.1 401 Unauthorized
  Content-Type: application/json; charset=utf-8
  Docker-Distribution-Api-Version: registry/2.0
  Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull"
  ...

Clients can consider them opaque, so I've left them out of the
distribution-spec project for now.  If distribution-spec maintainers
feel that clients could benefit by explicitly crafting their own scope
strings, they can pull in the scope specification after the project
forms.

JWT token semantics [4] are part of the interface between the auth
server and the registry.  Clients can consider them opaque, so I've
left them out of the distribution-spec project.

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope language is from Stephen in [5].  The discovery
scope language is from Derek [6].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md
[3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md
[4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md
[5]: opencontainers#35 (comment)
[6]: opencontainers#34 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 26, 2018

distribution: Also move the Bearer token and OAuth docs
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  So folks writing a client that will interact
with a Docker registry that uses that auth approach will need a
"Docker registry's 'Bearer' additions" spec to follow.  While I prefer
off-the-shelf RFCs for HTTP auth, the Docker registry additions are
small enough, and widely used.  This change adds the client side of
their specification to the new distribution-spec project.

The docker/distribution repository also includes docs for scope [3]
and the JWT token semantics [4].  The scope docs are borderline useful
for clients, but I've left them out because clients can extract the
required scope from WWW-Authenticate in 401ed responses:

  $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1
  HTTP/1.1 401 Unauthorized
  Content-Type: application/json; charset=utf-8
  Docker-Distribution-Api-Version: registry/2.0
  Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull"
  ...

Clients can consider them opaque, so I've left them out of the
distribution-spec project for now.  If distribution-spec maintainers
feel that clients could benefit by explicitly crafting their own scope
strings, they can pull in the scope specification after the project
forms.

JWT token semantics [4] are part of the interface between the auth
server and the registry.  Clients can consider them opaque, so I've
left them out of the distribution-spec project.

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope language is from Stephen in [5].  The discovery
scope language is from Derek [6].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md
[3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md
[4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md
[5]: opencontainers#35 (comment)
[6]: opencontainers#34 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 26, 2018

distribution: Also move the Bearer token and OAuth docs
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  So folks writing a client that will interact
with a Docker registry that uses that auth approach will need a
"Docker registry's 'Bearer' additions" spec to follow.  While I prefer
off-the-shelf RFCs for HTTP auth, the Docker registry additions are
small enough, and widely used.  This change adds the client side of
their specification to the new distribution-spec project.

The docker/distribution repository also includes docs for scope [3]
and the JWT token semantics [4].  The scope docs are borderline useful
for clients, but I've left them out because clients can extract the
required scope from WWW-Authenticate in 401ed responses:

  $ curl -IH 'Accept: application/vnd.docker.distribution.manifest.v2+json' https://index.docker.io/v2/library/docker/manifests/1.12.1
  HTTP/1.1 401 Unauthorized
  Content-Type: application/json; charset=utf-8
  Docker-Distribution-Api-Version: registry/2.0
  Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/docker:pull"
  ...

Clients can consider them opaque, so I've left them out of the
distribution-spec project for now.  If distribution-spec maintainers
feel that clients could benefit by explicitly crafting their own scope
strings, they can pull in the scope specification after the project
forms.

JWT token semantics [4] are part of the interface between the auth
server and the registry.  Clients can consider them opaque, so I've
left them out of the distribution-spec project.

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope language is from Stephen in [5].  The discovery
scope language is from Derek [6].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/oauth.md
[3]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/scope.md
[4]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/jwt.md
[5]: opencontainers#35 (comment)
[6]: opencontainers#34 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 26, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope language is from Stephen in [3].  The discovery
scope language is from Derek [4].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 29, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 29, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 29, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 29, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 29, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/opencontainers-tob that referenced this issue Jan 30, 2018

distribution: Add in-scope and out-of-scope wording
Docker's use of Bearer requires information beyond what's covered in
RFC 6749 and 6750 [1].  Folks writing a client that will interact with
a Docker registry that uses that auth approach will need a "Docker
registry's 'Bearer' additions" spec to follow, but Derek believes the
situation is salvageable with external work [2].

Also pin the docker/registry links to a specific version so the links
will survive future docker/registry changes (including removing the
docs after the OCI picks them up).  As long as the TOB-selected
version isn't far behind (how far will the spec move during a week of
voting?), it should be easy for the new maintainets to catch up on any
subsequent drift.

The signing scope is from Stephen in [3].  The discovery scope is from
Derek [4].  The content-management scope is from Stephen [5] and Liang
[6].

This commit also add's Mike's interoperability statement [7], which
mentions one reason for the OCI inclusion is the
implementation-agnostic location where implementers can collaborating
on a common specification.  The project scoping is open to drift with
the limits imposed by the TOB's scope table.  If the TOB thinks
subsequent drift is excessive, they are free to make further
scope-table adjustments in follow-up proposals.

I've also added Mike's library/busybox scoping example [8].

[1]: xiekeyang/oci-discovery#64 (comment)
[2]: opencontainers#37 (comment)
[3]: opencontainers#35 (comment)
[4]: opencontainers#34 (comment)
[5]: opencontainers#35 (comment)
[6]: opencontainers#37 (comment)
[7]: opencontainers#35 (comment)
[8]: opencontainers#37 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Feb 27, 2018

Contributor

Just an update here, now that the new @opencontainers/tob is elected, I will be working on updating the proposal to get it in shape for a vote some time next month. Let me know if there are any concerns about the timeline.

Contributor

caniszczyk commented Feb 27, 2018

Just an update here, now that the new @opencontainers/tob is elected, I will be working on updating the proposal to get it in shape for a vote some time next month. Let me know if there are any concerns about the timeline.

@wking wking referenced this issue Mar 1, 2018

Closed

Loosen restrictions #44

@caniszczyk

This comment has been minimized.

Show comment
Hide comment
@caniszczyk

caniszczyk Mar 12, 2018

Contributor

I kicked off the official project creation vote here for the OCI TOB to approve:

https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/dU6uXM__ilU

Contributor

caniszczyk commented Mar 12, 2018

I kicked off the official project creation vote here for the OCI TOB to approve:

https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/dU6uXM__ilU

@caniszczyk

This comment has been minimized.

Show comment
Hide comment

@caniszczyk caniszczyk closed this Apr 9, 2018

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Apr 9, 2018

Contributor
Contributor

wking commented Apr 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment