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-
Matt Ball <>
Sent by:
04/27/2009 09:26 AM
To
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
