Possible solution to referencing issues

[Patrick Durusau <patrick@durusau.net>]

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

Greetings!

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

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

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

iQIcBAEBAgAGBQJTNur6AAoJEAudyeI2QFGoLUIP/jMacR32o7PNkXwKWXQr+5cY
u+b+xMBqAfWoxeZPrsxqR/QK0T4/KmBPTl/8P7fmSRU4BhgGxL4WX2MEzPUbG+7w
97JTiNY4ujr2DqGMOFdwPZ8YSY8heFA2tZb4bYNzkTCwnQvrU/yoLfnjYO8xKE/i
UHBk6MHLY++zMOb6zDQTcJOrwo2yz/EuskBcAJdSiO3Xn9+wUs/9crtw+0AA9jja
456/CvipaMJCpr7kI3yWNrM6qD8BV3RuVYr9tvKXml5w++Fxtyd3PX0QGd+19do3
9YsvfdzGZbXgjwchGcMfJxCucmgXx1o+/NUqxbGZXeLxMmUxaI8bSrFxL1WSFkjS
VPOYeSKZ3ndo41kNpYkPuYZDNqHM5VTLfoAhFVQr/xowl04Z3+3RDoU/eIaaB7Fi
F7F9bNuorAcBV+V9FNEjBOYiq0jEUJq5jFw/1W+gbsgytsNIxvR/LLIclpQNipPw
VrCJI5WjE+gxPUyN5J2itvUwTIwkRCXIf+2zpQEmku14nsAOLbXaq26whEngtbCd
CvPaI2wpcJjRbNjJauW9PW9q8bZN8vqZs00ydyyzy4Ff0MpEOZFn60AHxVbxirjg
5Gbl9fWok6wfPkMfK1F7sXVg5UWto4BY/RnBRChLpNa89rRQKfyYot1bw9k4L5Y5
e13kq4aOAuEQOdlqJLsv
=Ileu
-----END PGP SIGNATURE-----