[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Suggestion regarding v1.4 errata
I think the question we need to answer is whether the change to the specification is âNon-Materialâ. The OASIS rules at first glance are pretty clear on the definition of Errata (https://www.oasis-open.org/policies-guidelines/oasis-defined-terms-2018-05-22): "Errata" is a set of
Non-Material corrections to an
OASIS Standard that have not yet been approved by an OASIS
Technical Committee or
Project Governing Board as an
Approved Errata. But this definition depends on the definition on âNon-Materialâ: "Non-Material Change" is any change to the content of a Work Product that does not add or remove any feature of the Work Product and that: (a) constitutes only error corrections, editorial changes, or formatting changes; or (b) is
a pro forma change to content required by TC Administration. I think we all agree that the 1.4 specification can be interpreted to a) require support for the State Attribute and therefore state-changing related Operations for Opaque Objects, or b) it can be
interpreted to mean that Opaque Objects do not have a State Attribute, and therefore related state-changing Operations are not relevant. I think we all agree that either interpretation is possible, and valid. Given that some vendors have implemented Cryptographic
Objects with State, and some others have not (and the number of vendors for each case is greater than one), it is a fact that we do not all agree on a single, âcorrectâ interpretation. So, we are in the position now where an error in the specification has resulted in different server implementations that MAY cause interoperability issues. It is possible to develop client applications
that do not have interoperability issues if operations are not requested by a client when different server implementations may behave differently; e.g. if a client never attempts to Activate or Revoke an Opaque Object, the client will not run into interop
issues due to these operations. It would be perfectly possible to develop profiles for âstatelessâ Opaque Objects, and âstatefulâ Opaque objects. But more importantly it is possible to create a profile that works for both stateless and stateful Opaque Objects.
This means that even with different server implementations it is possible to specify and implement profiles that are fully interoperable with both interpretations. Getting back to material vs. non-material change. By changing the specification through errata for Opaque Objects to require support for state, existing server implementations that do not support
state for Opaque Objects would be materially impacted. Pre-errata these server vendors can claim that the server implementation is in accordance with a valid interpretation of the specification. Post-errata, these vendors cannot make this claim. In my opinion
this is a material change. I would argue that to require support for State by Opaque Objects adds a feature that was not present in a currently valid interpretation of the 1.4 standard. Similarly, removing support for State by Opaque Objects is a material
change due to the fact that it removes a feature that was not present in another currently valid interpretation of the 1.4 standard. The result of correcting the error by editing text to add state to an Opaque Object would be equivalent to adding a feature to the Work Product, and by OASISâ definition, this is a material change. Would it make more sense to go down the path of simply describing how to remain interoperable with 1.x servers that have been implemented with different interpretations of Opaque Object requirements?
I think this would be the least disruptive approach. John From: kmip@lists.oasis-open.org <kmip@lists.oasis-open.org>
On Behalf Of Tim Hudson The challenge in this context is we have statements in the specification which are effectively technically contradictory but in reality are actually quite clear from context. In one location we are simply missing an object type in the list of applies-to in a table - a very simple act of omission. In multiple other locations there are clear statements which show that opaque objects change state and have state change impacts on attributes. There isn't actually anything within the specification beyond the simple omission error to indicate the technical committee
ever had the intent to actually preclude opaque objects from having state. In the past when we have hit issues where there is a non-interoperable context we have explored options but ultimately gone with the
majority view point based on the impact of the change in terms of impacted vendors. Leaving this non-interoperable context as-is really isn't something that is consistent with the whole purpose of the technical committee (and OASIS) - which is interoperable results. In terms of conformance - you have to actually go to the profiles document itself - the specification text explicitly passes all conformance across to the profiles. So no one can actually claim conformance to the base specification (that has no meaning) - you have to specify which profiles you conform to (which in turn specify the items in the specification). There is only one profile that covers Opaque Objects - the Opaque Managed Object Store - and it covers only a simple register with a Name - and does not address State one way or the other. We have a simple decision making process in the TC - and based on the call this week we will end up with clear change documents for consideration on next weeks call. Tim. On Fri, Jan 25, 2019 at 9:00 AM John Major <jmajor@quintessencelabs.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]