Pin down our JSON definition to a particular RFC (which we can
explicitly bump if neccessary), instead of referencing the floating
JSON homepage.
Explicitly make objects unordered and forbid duplicate names to avoid
relying on unportable behavior. RFC 7159 is a bit more relaxed [1]:
The names within an object SHOULD be unique.
but warns [1]:
An object whose names are all unique is interoperable in the sense
that all software implementations receiving that object will agree
on the name-value mappings. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicates.
The RFC also warns about order portability [1]:
JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.
And has some (informative?) language about entries being unordered
[2]:
An object is an unordered collection of zero or more name/value
pairs...
[1]: https://tools.ietf.org/html/rfc7159#section-4
[2]: https://tools.ietf.org/html/rfc7159#section-1
Signed-off-by: W. Trevor King <wking@tremily.us>
In all of these cases we want to use the RFC 2119 semantics.
Generated with:
$ sed -i 's/required/REQUIRED/g' config*.md
after which I rolled back the change for:
...controllers required to fulfill...
since that was already MUSTed.
Signed-off-by: W. Trevor King <wking@tremily.us>
In all of these cases we want to use the RFC 2119 semantics.
Generated with:
$ sed -i 's/optional/OPTIONAL/g' config*.md
Signed-off-by: W. Trevor King <wking@tremily.us>
We don't want to silently ignore settings that we understand but
cannot implement [1] (we *do* want to ignore settings that we don't
understand [2], but that's a separate issue).
This raises a slightly sticky certification issue. If a runtime
*always* exits 'create' with an error:
func create() err {
return fmt.Errorf("nope, I cannot create that container either.")
}
it would be neither complaint nor non-compliant. It would not fail
any MUSTs, but availing itself of the "cannot create the maintainer"
option specified in this commit would mean the test suite could not
test the deeper requirements around the config properties themselves.
So with this change, making Microsoft certifiable will still need an
explicit weakening around root.path. The easiest way to do that might
be to have separate annotations for whether a setting is optional for
config authors and whether it's optional for runtime authors
(supported):
* **`readonly`** (bool, config:optional, support:optional) ...
But I'll leave hashing that out to a later commit. Regardless of the
certification impact, we want to be clear that silently ignoring known
parameters is wrong.
[1]: 9b8e21826c (r65400731)
Subject: [ Config | Root Config ] Clarify readonly
[2]: https://github.com/opencontainers/runtime-spec/pull/510
Subject: Add text about extensions
Signed-off-by: W. Trevor King <wking@tremily.us>
We dropped these in 47740802 (specs-go/config: Drop "this field is
platform dependent", 2016-09-14, #568) but f9e48e00 (Windows: User
struct changes, 2016-09-14, #565) was developed in parallel and
brought in a new one.
Signed-off-by: W. Trevor King <wking@tremily.us>
Michael Crosby
Zhang Wei
Qiang Huang
Mrunal Patel
Ma Shimiao
Lei Jitang
Vincent Batts
W. Trevor King
John Howard
Jonathan Boulle