OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
Expand all | Collapse all

Groups - Sun 32-bit Binary Alignment Proposal (Sun 32-bit Binary Alignment Proposal.pdf) uploaded

  • 1.  Groups - Sun 32-bit Binary Alignment Proposal (Sun 32-bit Binary Alignment Proposal.pdf) uploaded

    Posted 04-29-2009 18:48
    Here is version 1 of the Sun 32-bit Binary Alignment Proposal.  I'm hoping
    to discuss this during tomorrow's KMIP meeting, and to move for its
    acceptance if there is general consensus.  Please send me any word-smithing
    comments beforehand so that we don't use up meeting time unnecessarily.
    
    Thanks,
    -Matt
    
     -- Mr. Matthew Ball
    
    The document named Sun 32-bit Binary Alignment Proposal (Sun 32-bit Binary
    Alignment Proposal.pdf) has been submitted by Mr. Matthew Ball to the OASIS
    Key Management Interoperability Protocol (KMIP) TC document repository.
    
    Document Description:
    This document is a proposal against KMIP v0.98 to change the alignment of
    the binary encoding to fall on 32-bit boundaries, optimizing the layout for
    hard-aligned processors, such as the ARM.
    
    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=32314
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/32314/Sun%2032-bit%20Binary%20Alignment%20Proposal.pdf
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  Proposal outline: Key naming for media interchange

    Posted 04-29-2009 20:02
      |   view attached

    Attachment(s)

    ppt
    kmip-naming-v1.0.ppt   83 KB 1 version


  • 3.  RE: [kmip] Proposal outline: Key naming for media interchange

    Posted 05-07-2009 03:28
    Stan -
    
    The concept has definite applicability to my needs and I would be
    interested in seeing more specifics on moving this forward.
    
    - Peter 
    
    


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

    Posted 04-29-2009 21:05

    On Apr 29, 2009, at 11:47 AM, <matthew.ball@sun.com> wrote:

    Here is version 1 of the Sun 32-bit Binary Alignment Proposal.  I'm hoping
    to discuss this during tomorrow's KMIP meeting, and to move for its
    acceptance if there is general consensus.  Please send me any word-smithing
    comments beforehand so that we don't use up meeting time unnecessarily.


    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.

    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.

    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.

    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






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

    Posted 04-29-2009 22:00
      |   view attached

    Attachment(s)

    vcf
    matthew_ball.vcf   330 B 1 version


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

    Posted 04-29-2009 22:13

    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