[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Feedback on binary alignment proposal
I agree with Matt, Glen, and BobL on 4-byte alignment
of all KMIP protocol elements, and with BobL on keeping lots of headroom in the
enumeration spaces.
I have seen entirely too much R&D effort over the past
38 years spent on kludging and extending opcode/name/address
spaces. It's ~another bit per year, whether you like it or not, so
plan ahead. If you want an architecture to last 16 years, add 2
bytes. So I would advise 4 bytes tag, 4 bytes type, 4 bytes length, 4N
bytes value. In 3 years or so, nobody will care about brevity, they will
be worrying about hitting limits.
My 2 or 3 cents.
Steve Wierenga
HP Secure Advantage From: Robert Lockhart [mailto:Robert.Lockhart@thalesesec.com] Sent: Monday, April 27, 2009 7:08 PM To: kmip@lists.oasis-open.org Subject: RE: [kmip] Feedback on binary alignment proposal I see several reasons for
ensuring that we keep both the Tag and type their current 4 byte
lengths. We are still under
255 tags (156) but we are planning to
define server to server at some point in the future (v2.0 and beyond) and
there are extensions that we want to allow for. I wouldn't want to
hamstring ourselves by not planning for it now. Plus we don't know what may change for the clients
in later versions of the standard that might be useful to this type of
device. I think we should
set the expectation now before people potentially code themselves into a corner
by accident.
The other issue we
would have is that it would limit or remove the number of extensions that
we might want to allow either via registration or assignment in the future for
other standards that want to make use of KMIP.
I agree with the four byte boundaries but
don't want to limit ourselves. If we do this I like Glen's suggestion in
1C and I don't know how soon we will hit 256 types but I am thinking it will
take a little longer to generate them than it would to create another 99 new
tags (thinking of server to server & extensions).
My 2 cents for the day,
Bob L.
Robert A. (Bob) Lockhart
Senior
Solutions Architect THALES
Information Systems Security ------------------------------------------------------- T: +1 408 457 7711
(Direct) M: +1 510 410
0585 F: +1 408 457
7681 E:
rlockhart@ncipher.com nCipher product line.
See www.nCipher.com From: Glen Jaquette [jaquette@us.ibm.com] Sent: Monday, April 27, 2009 5:28 PM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Feedback on binary alignment proposal Matt, I do see value in revising the TTLV protocol to align it to 4 byte boundaries, I think we just have to work through the details to make sure we find the best trade-off. Here are my thoughts: Your proposal devolves into 2 main ideas which are essentially separable:
As far as #1 above, I would suggest we consider 1C. As far as #2, I don't see how to improve on your proposal. Regards, Glen Jaquette IBM Distinguished Engineer (520) 799-2192; fax: -4138; tieline 321-
Hi Folks, If you have any preferences regarding the encoding choices from last Friday's binary alignment presentation, please send them to me by tomorrow so that I can incorporate them into the first revision of the proposal. I plan to have the full proposal ready for discussion during Thursday's meeting, if there is time available on the agenda. Thanks! -Matt View Document Details: http://www.oasis-open.org/committees/document.php?document_id=32244 Download Document: http://www.oasis-open.org/committees/download.php/32244/Sun%20KMIP%20Alignment%20Proposal.pdf --------------------------------------------------------------------- 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 The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]