Next in thread → Next in month →

Re: [kmip] Groups - Sun 32-bit Binary Alignment Proposal (Sun 32-bit Binary Alignment Proposal.pdf) uploaded

From
Kon Dallas
Date
2009-04-29T22:12:30+00:00
ID
Thread
Re: [kmip] Groups - Sun 32-bit Binary Alignment Proposal (Sun 32-bit Binary Alignment Proposal.pdf) uploaded
On Apr 29, 2009, at 2:59 PM, Matt Ball wrote:
 
 
Hi Jon:  See Below:
 
 Jon Callas wrote:
 > I think it needs to be more clear about padding in strings. It's
 > pretty explicit that bignums get padded out to 32-bits and how, and it
 > appears that strings are also padded out, but it's not clear. If they
 > are padded, there needs to be language, and if they are not, there
 > also should be language as well as a discussion. If strings aren't
 > padded, then there's little need to do this change, as the first
 > string will dealign everything.
 I'm hoping that the current language covers this, although I'm happy to
 add clarifying language.  The Item Length field contains the unpadded
 length of the strings and structures.  The padding is covered by this
 statement at the end of the Item Value section:  "If the Item Length
 contains a value that is not a multiple of 4, then the contents of the
 Item Value shall be padded with one, two, or three trailing ‘00’ bytes
 such that the transmitted length is a multiple of 4 bytes (32 bits)."
 This statement implicitly covers Text Strings, Octet Strings, and
 Structures.
 
 How about I add language at the end of 9.1.1.3 "Item Length" clarifying
 that the length for Text Strings, Octet Strings, and Structures is the
 unpadded length?

Yes, and an explicit note that they are also padded out to a longword.

 > The type for Structure used to be 80 in a byte. Should it be 80000000
 > now? I'm presuming it should, otherwise it would have been 0A before.
 This is before my time, so I'm happy either way.  Can anyone explain the
 rationale behind using 80 for the structure type value?
 > I think we should pick one of "byte" and "octet." In this day and age,
 > non-octet bytes are either a specialized term of art or charmingly
 > quaint. I see nothing wrong with an explicit statement in the
 > introduction that "byte" means "octet," but it's confusing to see both
 > as it implies there's a difference. Just pick one and use it.
 Consistently using either byte or octet makes sense to me, although I'm
 hoping to separate that battle from this proposal. :)
 
 But since this will eventually be a discussion topic I'll throw in my
 thoughts:  Since this is a network protocol, my preference is to use
 only the word 'octet' and ban the use of 'byte' entirely, following the
 lead of IETF.  My opinion would be the opposite for a storage standard
 (like IEEE 1619, 1619.1, or 1619.2), where 'byte' seems to be the
 preferred term.

Again, I have no preference for anything other than consistency. Pick one and use it.

	Jon

 

-- 

Jon Callas         

CTO, CSO           

PGP Corporation         Tel: +1 (650) 319-9016

200 Jefferson Drive     Fax: +1 (650) 319-9001

Menlo Park, CA 94025    PGP: ed15 5bdf cd41 adfc 00f3

USA                          28b6 52bf 5a46 bc98 e63d
Next in thread → Next in month →