runtime: Clarify "new runtime states" and the flexibility of state status?

[wking]

Since we added status to the state model in #462, we've had

Additional values MAY be defined by the runtime, however, they MUST be used to represent new runtime states not defined above.

With #507 delayed until after 1.0, I'd like to get more clarity on what that means. I'd assume it means something like:

As long as nobody has done anything outside of the standard operations, any state requests MUST return one of the above statuses. If somebody does something else (e.g. calls runc pause …), the status returned in subsequent state requests is implementation-defined.

In that case, landing #507 would be a breaking change for state consumers (although the spec version is bound to the config format, #523, and we don't actually version the state schema (we just echo the config version). And a runtime which used creating as proposed in #507 would be non-compliant.

But maybe the intention was more like:

Runtimes MAY define additional values, but if they define a status entry with exactly the same condition wording as one one of the above statuses, they MUST use the same name. For example, a runtime cannot define:

exited: the container process has exited

because this specificaction already defines stopped for that condition.

In that case, a runtime which used creating as proposed in #507 would be OCI compliant.

Regardless of if/when #507 lands, I think we should do one of:

a. Reword this line to clarify “new runtime states”,
b. Drop the MUST restriction, make the values of status implementation-defined, and SHOULD the values defined in the spec, or
c. Drop the MAY flexibility, and REQUIRE runtimes to only use status fields defined in the spec.

My personal preferences if for (a) or (c), to allow for uniform triggering on standardized events (e.g. #508). (b) is less useful (why define the field in the spec at all if you don't have reliable values?), but it is at least clear that the values may not be portable between runtimes (while with the current phrasing, different readers might disagree on whether the values are portable).

[wking]

I'd still like to have this resolved by 1.0 because I think it makes backwards compatibility unclear. But it's been open 5 months without any comments, so I doubt anyone is going to weigh in before 1.0. And of my open issues/PRs, I feel this one is less pressing. Can a maintainer tag this v1.NEXT-maybe?