re: [kmip] Clarification questions

[<robert.griffin@rsa.com>]

Hi Terence -

Thanks for the questions/issues. We wrestled with similar implementation
questions in the proof-of-concept work, but I don't recall that these
two particular areas of clunkiness surfaced.

I'd like to discuss these in the call tomorrow, to determine if they are
important enough from the point of view of the TC to address before we
go to public review. Will you be able to join us on the 11 am TC call?

Regards,

Bob



-----Original Message-----
From: Terence Spies [mailto:terence@voltage.com] 
Sent: Wednesday, October 14, 2009 2:25 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Clarification questions

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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php