OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[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-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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]