OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [kmip-comment] Possible solution to referencing issues

Hash: SHA1


But the problem isn't that every profile must cover all three versions
of the specification. That would be bad enough.

Given the profile documents for each specification, every profile must
treat all 6 specifications and profiles. (As they attempt to do and
fail currently.)

Given 9 profiles, that 54 total references across 6 specifications and

And every new profile will add another 6 mappings. I am sure as time
goes by the TC will want to create more profiles and perhaps later
versions of the specs + profiles.

Unless the TC addresses this issue now, with something more than it
has considered the problem and is going forward as is, the situation
is going to get worse, far worse.

The reliance on "work flows" to avoid specifying behaviour in prose
signals that no one can specify the "work flow," you can only specify
some subset of values and then the protocol "should work like this."

Standards are not made out of subsets of allowed values. Standards
specify ranges of values to which any implementation can conform.

Hope you are having a great weekend!


On 03/29/2014 06:39 PM, Tim Hudson wrote:
> On 30/03/2014 1:47 AM, Patrick Durusau wrote:
>> First, let me confirm that KMIP-Spec 1.2 is a superset of
>> KMIP-spec 1.1 and KMIP-spec 1.0.
> There are behaviours within KMIP-Spec 1.2 that are not compatible
> with KMIP-Spec 1.1 and KMIP-Spec 1.0 and they have to be referred
> to separately and each version of the specification documents a
> particular major.minor version of the protocol. Make it clearer -
> KMIP-Spec 1.2 does not document KMIP protocol version 1.0 or
> protocol version 1.1. Each specification is independent of the
> other specifications and the profiles have to cover all three
> versions of the specification.
> The test cases document the normative conformance message flows
> and values and the allowed variations document where an
> implementation is permitted to vary the details form the normative
> message flows - that is their point and function. The profiles
> document a set of messages that represent the minimal message flows
> required for conformance to a given profile.
> As a technical committee we explored a number of different
> approaches for handling cross-version references and for handling
> documented conformance requirements and the approach we have in the
> profile documents represents the one which allows specification of
> conformance sufficiently precisely to meet the interoperability
> objective.
> Thanks, Tim.

- -- 
Patrick Durusau
Technical Advisory Board, OASIS (TAB)
Co-Chair, OpenDocument Format TC (OASIS)
Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]