Validation strictness

[wking]

Refs can point to whichever type they like (although they usually point at manifests or manifest lists). How should we handle validation when a ref points at a single layer? Or at a config? Or at an image/png? I see a few interesting settings:

• --unpackable, for “can image-tools unpack this content?”. This would be true for manifests, manifest lists, and (once we land support for it) layers, but would not be true for configs (because diffIDs are not neccessarily fetchable from CAS).

• --strict, for “does the validated object only contain content which the OCI defines (or references) in the spec?”. In that case, refs pointing to manifests, manifest lists, configs, or layers would all
  be legal. Other types would trigger validation errors.

• --base, for “does the validated object only contain content which the OCI requires unpackers to support?”. This would be true for manifests and layers, but not for manifest lists, configs, or other
  types. There has been talk about requiring unpacker support for manifest lists, we currently only SHOULD support for them. If we MUST support for them, then there may not be any need for --base (since it would cover the same types as --strict).

In cases where the user specified none of --unpackable, --strict, or --base, I'd rather warn (but not error) on this sort of thing. And using TAP (as described in #60) gives us a convenient way to warn
without erroring.

[xiekeyang]

@wking
If manifest, manifest list and single layer are unpackable? I'm not sure, but could you present some use case for that?

[wking]

A use case for unpacking a single layer? Maybe unpacking a manifest is not giving you the results you expect, and you want to step through the layers one by one.