Hi Folks,
I've got the alignment proposal ready, but would like to give
interested parties a chance to get a sneak preview. I will publish the
proposal to OASIS tomorrow at this same time. If you would like to get
a copy of this preview, please let me know, and I'll send you a copy.
Thanks!
-Matt
Matt Ball wrote:
49F70391.5070908@sun.com" type="cite">
It sounds like the group has converged on proposal 1B, which is to
keep the tag field unchanged and increase the type field size to 4
bytes.
If this is acceptable, I plan to have the proposal written up and
posted within the next couple hours... :)
Cheers,
-Matt
Wierenga, Steven wrote:
31959AEB7013DE41BDDF808CCFFA0CED4CB55045AB@GVW0432EXB.americas.hpqcorp.net"
type="cite">
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
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
W: www.nCipher.com
nCipher product line. See www.nCipher.com
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:
- You observe that
the present composition is essentially a 4 byte Tag followed by a 1
byte Type field (i.e. (4-byte Tag = 0x42.00.00.YZ)) which
immediately throws off the 4 byte alignment, and this is a first
thing that needs to be addressed. There are various ways to address
that:
- The specific
proposal you illustrated on slide 6 is option 1.1 from slide 5 --
namely to drop the leading byte of the four Tag field, which is 0x42
in all cases today, making it effectively a 3 byte Tag. Then you
transpose the Type and Tag fields, giving:
- (1-byte Type) |
(3-byte Tag = 0x00.00.YZ)
- => Pro: this
decreases the number of bytes which need to be communicated to give
both Tag and Type by one
- => Con: in
response to which a Tony and Jon observed that this eliminates the
0x42 which has proven useful in the testing so far
- Someone else
(didn't catch the name) suggested that instead we just pad Tag out to
4 bytes, or effectively:
- (4-byte Tag =
0x42.00.00.YZ) | 4-byte Type)
- => Pro: this
preserves the 0x42.00.00 that can be used to distinguish the start of
a new Tag, and hence the start of a new TTLV message
- => Con: this
increases the number of bytes which need to be communicated to give
both Tag and Type by three
- A third option
which occurs to me is a variation of option 1.2 from your slide 5,
namely to cut a different byte from the Tag (0x00 instead of 0x42)
and then not transpose or effectively:
- (4-byte Tag =
0x42.00.YZ) | 1-byte Type)
- => Pro: this
decreases the number of bytes which need to be communicated to give
both Tag and Type by one (i.e. same as 1A)
- => Pro: this
preserves the first two of the distinguishable bytes (i.e. 0x42.00)
that can be used to distinguish the start of a new Tag, and hence the
start of a new TTLV message, though one could argue that is slightly
less than the 3 bytes that exist today.
- Similarly make the
Value modulo 4 bytes by:
- Padding binary
fields out to the next 4 byte boundary
- Making BIGNUM
fields an integer number of 4 byte fields long
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.
---------------------------------------------------------------------
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
|