Re: [kmip] Suggestion regarding v1.4 errata

[Tim Hudson <tjh@cryptsoft.com>]

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:

Hi,

Â

I have a suggestion for this errata that may be a little outside the box at this point.

Â

First, my understanding of the oasis errata rules, quoted in the recent call, is that they aim to prevent a compliant instance in the field from becoming non-compliant by a documentation change. There are server implementations, in the wild, that claim 1.4 compliance and they differ from each other in some aspects. There are clients, in the wild, expecting different behaviours depending on their interpretation of the spec. All of these are currently considered compliant. None of these should be made non-compliant by an errata.

Â

With this in mind, I suggest that any errata should

• Clarify the original intent.
• Document the existing discrepancies found in the wild.

Â

Any new test case that changes the compliance of deployed software would, I feel, hit the spirit of the Oasis definition of material change, if not the letter.

Â

Regards

John Major

Â

John MajorÂ| Software DeveloperÂ| QuintessenceLabs | W: quintessencelabs.comÂ

Unit 1 Lower Ground |15 Denison St | Deakin ACT 2600 | P: +61 2 6260 4922Â

Check out our new website: quintessencelabs.com

ÂÂ

Â