@@ -93,28 +93,7 @@ to another node in the cluster. This will be introduced in a backward compatible

 We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a

 *debugging* feature, as well as being strongly dependent on the Runtime ingredient effort.

-## 2.2 Dockerfile syntax

-

-The Dockerfile syntax as we know it is simple, and has proven successful in supporting all our

-[official images](https://github.com/docker-library/official-images). Although this is *not* a

-definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several

-reasons:

-

-  - Long term impact of syntax changes is a sensitive matter that require an amount of attention the

-    volume of Engine codebase and activity today doesn't allow us to provide.

-  - Allowing the Builder to be implemented as a separate utility consuming the Engine's API will

-    open the door for many possibilities, such as offering alternate syntaxes or DSL for existing

-    languages without cluttering the Engine's codebase.

-  - A standalone Builder will also offer the opportunity for a better dedicated group of maintainers

-    to own the Dockerfile syntax and decide collectively on the direction to give it.

-  - Our experience with official images tend to show that no new instruction or syntax expansion is

-    *strictly* necessary for the majority of use cases, and although we are aware many things are

-    still lacking for many, we cannot make it a priority yet for the above reasons.

-

-Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about

-what we want to do first!

-

-## 2.3 Remote Registry Operations

+## 2.2 Remote Registry Operations

 A large amount of work is ongoing in the area of image distribution and provenance. This includes

 moving to the V2 Registry API and heavily refactoring the code that powers these features. The