Hi KMIPers,
I realize that I'm pretty late to the party here, but I have two low
level questions about the spec. If these have been hashed out
previously, my apologies. These are both basically stylistic
quibbles, but if they can make implementations even slightly easier,
might be worth at least a quick thought.
1) Given that every object has a nice TTLV tag, why do the operation
payloads all get a single tag? Right now, almost everything can be
cleanly unmarshalled from the TTLV into a local structure by switching
off the tag value, EXCEPT for payload objects, which require that the
operation value is passed around so that the TTLV layer understands
the context to parse and unpack the payload object. This also
prevents type checking the contents without carrying the operation
around. If the tag specified "create operation payload" instead of
"request payload", then it's obvious from the tag what is required to
come next.
2) The two parallel systems for referring to attributes is a bit
painful. Attributes can be named by a fixed tag value or by a
string. When I specify an attribute in an Attribute object, I'm
forced to translate from a tag to a string, or vice-versa when I refer
to an attribute inside a Key Block. I understand that there's a
desire to separate the attribute naming in the kmip layer proper from
the naming in the TTLV encoding, but no matter what choice I make for
my native representation of attributes, I either need to translate
from TTLV tags (when parsing out a Key Block) to strings, or from
strings (in an Attribute) to tag values that I store internally.
Referring to a small, finite number of unambiguous attributes by way
of strings seems a little clunky, in that it's easy to get those
strings wrong. Not to mention all the Z/OS guys that need to
understand that they are not EBCDIC, and non-english implementations
that have to keep these string representations floating around.
Again, sorry for catching up with you guys so late in the process, but
I thought I'd at least ask. Any clarifications on the design
decisions here (or mail pointing out that I've fundamentally
misunderstood something) welcomed.
I'm excited to be part of the group and the important work you folks
are doing.
Terence Spies
Voltage Security, Inc.