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: Possible solution to referencing issues

Hash: SHA1


I have been thinking about the referencing issues in the KMIP bundle
of drafts and have a suggestion that may solve several issues at once.

First, let me confirm that KMIP-Spec 1.2 is a superset of KMIP-spec
1.1 and KMIP-spec 1.0.

Well, with the exception that KMIP-SPEC 1.0 has

9.2 XML Encoding

2080An XML Encoding has not yet been defined.

10 Transport

2082A KMIP Server SHALL establish and maintain channel confidentiality
and integrity, and provide assurance
2083of server authenticity for KMIP messaging.

2084If a KMIP Server uses TCP/IP for KMIP messaging, then it SHALL
support TLS v1.0 [RFC 2246] or later
2085and may support other protocols as specified in [KMIP-Prof].

Which I did not see in KMIP-SPEC 1.1 or 1.2, at least by those names.

If that's true, then why not define the profiles against KMIP 1.2 and
in KMIP 1.2, define the data values, their allowed variants and the
various clients and servers?

So you could have in KMIP 1.2, a number of conformance clauses, one
example of which could read:

A KMIP Server - Version 1.1, MUST/SHOULD/MAY (I would do them in that
order) referencing back to clauses in KMIP 1.2.

+ however many other servers/clients you want to define.

That means that in your profiles, you only have to reference KMIP 1.2
and a defined server or client by section # in the conformance clause
of KMIP 1.2.

True, all of those may have been defined in KIMP 1.0, KMIP 1.1 and the
various profiles, but if we have all the properties we need in KMIP
1.2, why go reference chasing?

It reduces the burden both on the editors and on the users of the

BTW, where ranges of values are allowed, I would define those as part
of that property definition. Implementers should never have to look to
more than one place for a value definition, unless a profile extends
or restricts the range of a value in the main spec. Even there it
should be where you re-define the property for the profile.

The conformance clause in the profile becomes:

A conforming X MUST

1) MUST meet the requirements of KMIP-1.2 Spec, conformance Clause #
and title, and

2) MUST/SHOULD/MAY (all of your clauses here)

And just iterate over however many clients/servers you wish to modify
in the profile.

Leaves you free to have other profiles of KMIP 1.2,  including
defining new clients or servers that you didn't define in KMIP 1.2.

I think you will find this a much cleaner way to construct references
and simplify the spec and profiles.

The test cases of necessity only test one set of values out of all the
possible values. Which makes them very valuable but they don't define
conformance for an application that uses other values. You may want to
keep them for each profile but XML schemas, machine readable versions
and being in a non-normative annex would signal to implementers that
other versions of these tests are equally valid for this spec.

Hope everyone is having a great weekend!


- -- 
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]