[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] Groups - Sun 32-bit Binary Alignment Proposal (Sun 32-bitBinary Alignment Proposal.pdf) uploaded
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? > 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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]