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

[Patrick Durusau <patrick@durusau.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim,

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
profiles.

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!

Patrick


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
patrick@durusau.net
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTN1XyAAoJEAudyeI2QFGoEvAQAPCSqdI6xrSdSma0YM8/Plm5
w9m6WEDzCX6fQp1NtLcn3p6GcZsZhlKp1KqmEbtBQc3eK1eACUaMy0US8svI0/Wr
mGzfMdhbfAxRW1N87HTYbb/1qGAi4imFqHia76Kb6jmUlQqagHk6Zjajbh/CtKoP
HobLqzttHF+nVg9xByae9HjebUfmjhEdS8hKxro2frFUqa3k0kNI0+45x380RXmW
2R5F8omwC1jiFcXpuB+WSeW8SSfK/ChZ5W0d2ji5zClhhyVOOezEFarREBqxDi4b
Py3eqdsLo+HuGRCQNwOzQULMLZNzEiP4mjbAMiLog7OtM+Nn9bOqxVbhpkIuRODd
Pw88ArOVom/pxICjT5b1bIUr40N+fCrXwRc9Y834gyT4Ja0lGpCmYfUWZrBP3z8C
7J0ft/ktqgxQ1CiMD4V1N2WR0+ECzvlzRHKR1ywvtSKwerD0JKdAVTSCPM9dKVIP
1rkGAo0OHrISA23aub/BQG0X4ROZ7cu585bfA/HynPvlw116snJVWZzoDNTOUxVz
L3Qhf7ZD1IL6KxQStEfeXmPgnhjCXD8yOmO5pvPUzIpS2QCaAaMUb1gUrspkpBzE
eLHl40x3TP9GUJR3SQMfxMXH6VU4JPuiJRn2Ip1Qp1C5PFKGR3K/6bI/YuU87L+L
XUlmgwMdhgn8d8wzgRHv
=Ldr2
-----END PGP SIGNATURE-----