Clarification questions

[Terence Spies <terence@voltage.com>]

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.