runtime: Define "unspecified", "undefined", and "implementation-defined"

I had been unaware of formal distinctions between these terms until
Stephen Walli called it out [1] in the context of his suggestion to
use "implementation defined" for uploading
application/vnd.oci.image.layer.nondistributable.tar+gzip [2].  I
couldn't find anything as compact as RFC 2119 around this idea, but
linking to a section of the C99 rationale seems reasonable enough.
The PDF I'm linking is "Rationale for International Standard -
Programming Languages - C Revision 5.10 April-2003" and the referenced
content appears in section 3:

  The terms *unspecified behavior*, *undefined behavior*, and
  *implementation-defined behavior* are used to categorize the result
  of writing programs whose properties the Standard does not, or
  cannot, completely describe.  The goal of adopting this
  categorization is to allow a certain variety among implementations
  which permits *quality of implementation* to be an active force in
  the marketplace as well as to allow certain popular extensions,
  without removing the cachet of *conformance to the Standard*.
  Informative Annex J of the Standard catalogs those behaviors which
  fall into one of these three categories.

  *Unspecified behavior* gives the implementor some latitude in
  translating programs.  This latitude does not extend as far as
  failing to translate the program, however, because all possible
  behaviors are "correct" in the sense that they don't cause undefined
  behavior in *any* implementation.

  *Undefined behavior* gives the implementor license not to catch
  certain program errors that are difficult to diagnose.  It also
  identifies areas of possible conforming language extension: the
  implementor may augment the language by providing a definition of
  the officially undefined behavior.
  *Implementation-defined behavior* gives an implementor the freedom
  to choose the appropriate approach, but requires that this choice be
  explained to the user.  Behaviors designated as
  implementation-defined are generally those in which a user could
  make meaningful coding decisions based on the implementation's
  definition.  Implementors should bear in mind this criterion when
  deciding how extensive an implementation definition ought to be.  As
  with unspecified behavior, simply failing to translate the source
  containing the implementation-defined behavior is not an adequate
  response.

The "rationale for the C99 standard" link text seems pretty informal,
but that's what WG14 uses to refer to the document [3].  And I've got
the full title, revision, date, and referenced text in here in case
the link dies and there is any ambiguity about the particular revision
intended ;).

[1]: opencontainers/image-spec#233 (comment)
[2]: opencontainers/image-spec#233 (comment)
[3]: http://www.open-std.org/jtc1/sc22/wg14/

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

Author: wking

runtime.md

@@ -6,6 +6,8 @@ This file defines the OCI Runtime Command Line Interface version 1.0.0.
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119][rfc2119].
 
+The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified].
+
 ## Versioning
 
 The command line interface is versioned with [SemVer v2.0.0][semver].
@@ -230,6 +232,7 @@ $ echo $?
 See [create](#example) for an example.
 
 [bundle]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc4/bundle.md
+[c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18
 [capabilities.7]: http://man7.org/linux/man-pages/man7/capabilities.7.html
 [controlling-terminal]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_03
 [create]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc4/runtime.md#create