Re: [kmip] Feedback on binary alignment proposal

[Glen Jaquette <jaquette@us.ibm.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:

1. 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:
   1. 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
   2. 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
   3. 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.
2. Similarly make the Value modulo 4 bytes by:
   1. Padding binary fields out to the next 4 byte boundary
   2. 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-

Matt Ball <Matthew.Ball@Sun.COM>
Sent by: Matthew.Ball@Sun.COM

04/27/2009 09:26 AM

To	kmip@lists.oasis-open.org
cc
Subject	[kmip] Feedback on binary alignment proposal

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

matthew_ball.vcf