Re: [kmip] Feedback on binary alignment proposal

[Matt Ball <Matthew.Ball@Sun.COM>]

Jon Callas wrote:
> The only possible revision to this would be to do some 64-bit
> alignment. I mention this because there are/were machines (Alpha being
> one) that really liked 64-bit alignment.
>
> I am *not* suggesting making type/tag etc. be 64-bits. On such a
> machine, a pair of 32-bit quantities it fine because fetch-then-split
> is fast. The difficulty would be in an unaligned fetch or store. What
> you'd want to do would be to pad strings, bignums, etc. out to 64 bits.
>
> I bring it up because if we do that, now is the time.
>
>     Jon
>
Hi Jon,

This is fairly straight-forward to do.  If we make sure the
Tag/Type/Length fields all fit nicely within 64 bits (8 bytes), then we
could just require that the Value field also be padded to 64-bits. 
Here's what that could look like:

Tag:  3 bytes
Type: 1 byte
Length: 4 bytes
Value: multiple of 8 bytes

The tricky part here is dealing with the Tag field.  We need at least
16-bits of reserved Tag space, so one way to get around this is to use
the leading '42' to indicate a 'reserved' Tag, and then define something
like '54' (6 by 9) to indicate 'Vendor Specific', instead of burning the
second Tag byte as is done today:

24-bit Tag allocations:
00 00 00 - 41 FF FF: Unused
42 00 00 - 42 FF FF: Reserved for KMIP (same as existing codes with one
zero-byte removed from middle)
43 00 00 - 53 FF FF: Unused
54 00 00 - 54 FF FF: Vendor Specific Extensions
44 00 00 - FF FF FF: Unused

Compare this to the existing KMIP draft, which allocates these 32-bit Tags:
00 00 00 00 - 41 FF FF FF: Unused
42 00 00 00 - 42 00 FF FF: Reserved for KMIP (65536 values)
42 01 00 00 - 42 01 FF FF: Vendor Specific Extensions (65536 values)
42 02 00 00 - 42 FF FF FF: Unused

This gives the same amount of room for expansion as today (16-bits), and
still maintains ease of debugging and development with a known leading
character.

I'm happy with either this proposal or the existing 32-bit alignment
proposal, but in my opinion, this would be the cleanest for the long-term.

Cheers,
-Matt

begin:vcard
fn:Matt Ball
n:Ball;Matthew
org:Sun Microsystems, Inc.;Key Management
adr:;;500 El Dorado Blvd, Bldg 5;Broomfield;CO;80021;U.S.A.
email;internet:matthew.ball@sun.com
title:Staff Engineer
tel;work:303-272-7580
tel;fax:303-272-3023
tel;cell:303-717-2717
x-mozilla-html:TRUE
url:http://www.sun.com
version:2.1
end:vcard