considerations: DRY extensibility

As I suggested in the PR landing these blocks [1,2,3].  I've shifted
the extensibility section to a separate considerations.md, since it's
a generic policy that applies to both our manifest and manifest-list.

The extensibility requirements might arguably apply to our other JSON
types as well (like annotations, which were recently DRYed up in
f15a268, annotations: make a designated doc and DRY a bit, 2016-12-15,
opencontainers#501).  The new extensibility section sets the stage for that, but
I've left the other types off this commit to focus on making the
current requirements more DRY without changing the specified behavior.

My personal preference would be to have separate canonicalization.md
and extensibility.md files, but Jonathan wanted the single file:

On Mon, Oct 10, 2016 at 09:22:46AM -0700, Jonathan Boulle wrote [4]:
> Ehh, I preferred it where it was - now worried about death by a
> thousand files (extensibility, canonicalization, etc etc). Can we
> combine them (into a generic "considerations" document or similar),
> or just put this back?

[1]: opencontainers#164 (comment)
[2]: opencontainers#164 (comment)
[3]: opencontainers#164 (comment)
[4]: opencontainers#340 (comment)

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

Makefile

@@ -30,7 +30,7 @@ DOC_FILES := \
 	layer.md \
 	config.md \
 	annotations.md \
-	canonicalization.md
+	considerations.md
 
 FIGURE_FILES := \
 	img/media-types.png

canonicalization.md renamed to considerations.md

@@ -1,3 +1,8 @@
+# Extensibility
+
+Implementations that are reading/processing [manifests](manifest.md) or [manifest lists](manifest-list.md) MUST NOT generate an error if they encounter an unknown property.
+Instead they MUST ignore unknown properties.
+
 # Canonicalization
 
 OCI Images [are](descriptor.md) [content-addressable](image-layout.md).

manifest-list.md

@@ -71,10 +71,6 @@ For the media type(s) that this document is compatible with, see the [matrix][ma
 
     See [Pre-Defined Annotation Keys](annotations.md#pre-defined-annotation-keys).
 
-### Extensibility
-Implementations that are reading/processing manifest lists MUST NOT generate an error if they encounter an unknown property.
-Instead they MUST ignore unknown properties.
-
 ## Example Manifest List
 
 *Example showing a simple manifest list pointing to image manifests for two platforms:*

manifest.md

@@ -66,10 +66,6 @@ Unlike the [Manifest List](manifest-list.md), which contains information about a
 
     See [Pre-Defined Annotation Keys](annotations.md#pre-defined-annotation-keys).
 
-### Extensibility
-Implementations that are reading/processing image manifests MUST NOT generate an error if they encounter an unknown property.
-Instead they MUST ignore unknown properties.
-
 ## Example Image Manifest
 
 *Example showing an image manifest:*

spec.md

@@ -18,7 +18,9 @@ The goal of this specification is to enable the creation of interoperable tools
 - [Filesystem Layers](layer.md)
 - [Image Configuration](config.md)
 - [Annotations](annotations.md)
-- [Canonicalization](canonicalization.md)
+- [Considerations](considerations.md)
+    - [Extensibility](considerations.md#extensibility)
+    - [Canonicalization](considerations.md#canonicalization)
 
 # Notational Conventions