config: Collapse extensibility to a single MUST#916
Merged
tianon merged 1 commit intoopencontainers:masterfrom Dec 18, 2019
Merged
config: Collapse extensibility to a single MUST#916tianon merged 1 commit intoopencontainers:masterfrom
tianon merged 1 commit intoopencontainers:masterfrom
Conversation
Generating an error seems like one potential violation of the requirement to ignore unknown properties. Compliance testing for the ignore requirement can cite the MUST I've written here for any noticeable runtime activity around the unknown property without needing a error-specific MUST. We've had the two MUSTs since 27a05de (Add text about extensions, 2016-06-26, opencontainers#510), citing [1]. I'd asked for consolidated phrasing then [2,3], but hadn't followed up after the commit landed. I've left a line mentioning the error activity as non-normative clarification, but am also happy to drop that line completely. Also: * Update the unknown annotation entry to reference the generic extensibility section, because there's nothing annotation-specific in how we want runtimes to handle unknown keys. * Remove "reading or processing" language. This initially landed in 27a05de with a bump in b92cf90 (consistency and style fix, 2017-05-12, opencontainers#811). Some thought was put into this phrasing there [4,5] and earlier in opencontainers#510 [6], but we never got around to dropping this qualifier. However, the purpose of this qualifier is unclear to me. What is the point of compliance requirements for runtimes which don't read or process a configuration? [1]: opencontainers/image-spec#164 [2]: opencontainers#510 (comment) [3]: opencontainers#510 (comment) [4]: opencontainers#811 (comment) [5]: opencontainers#811 (comment) [6]: opencontainers#510 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Contributor
Author
|
Despite touching some MUST language, I consider this a patch-level change because the semantics are unchanged. Everything that was legal before is still legal, and everything that was illegal before is still illegal. |
Member
|
house keeping: this clarification does not break any versioning as the sentence with LGTM |
Member
|
LGTM |
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Generating an error seems like one potential violation of the requirement to ignore unknown properties. Compliance testing for the ignore requirement can cite the MUST I've written here for any noticeable runtime activity around the unknown property without needing a error-specific MUST.
We've had the two MUSTs since #510, citing opencontainers/image-spec#164. I'd asked for consolidated phrasing then, but hadn't followed up after the commit landed.
I've left a line mentioning the error activity as non-normative clarification, but am also happy to drop that line completely.
Also:
Update the unknown annotation entry to reference the generic extensibility section, because there's nothing annotation-specific in how we want runtimes to handle unknown keys.
Remove “reading or processing” language. This initially landed in Add text about extensions #510 with a bump in consistency and style fix #811. Some thought was put into this phrasing there and earlier in Add text about extensions #510, but we never got around to dropping this qualifier. However, the purpose of this qualifier is unclear to me. What is the point of compliance requirements for runtimes which don't read or process a configuration?