Re: JFK nit

[Dan McDonald <danmcd@east.sun.com>]

<SNIP!>

> >JFK authors, please address this problem.  If you want to discuss matters of
> >bit-twiddling import, let me know!
> >
> 
> We're completely agnostic about details like that.  "send text".

Okay!  Originally, you have this:

> 4.1  Structure
> 
>    Each message is a string of tag-length-value elements concatenated
>    together.  Tags are one octet.  Lengths are two octets, and specify
>    the number of octets of the value.  Values are always integral
>    numbers of octets.  All octets are in big-endian order.

Here is my proposed replacement text.  I'm not sure what the consensus is
w.r.t. 32-bit or 64-bit alignment.  That choice will be expressed in {32,64}
bit csh-style regexps.  (I.e. given {a,b}, if you want 32-bit, substitute a,
if you want 64-bit, substitute b.)

4.1  Structure

    Each message is a string of tag-length-values elements concatenated
    together.  Each TLV element is alignable on a {32,64}-bit boundary.  Tags
    are two octets, and lengths are two octets.  Lengths specify the number
    of octets of the value.  A subsequent tag is read at the next {32,64}-bit
    boundary.  Computing the offset of next boundary from the current
    element's length is straightforward: ((len + {3,7}) / {4,8}) * {4,8}.
    Any octets needed for alignment padding MUST be set to zero.


NOTE FOR 64-Bit FOLKS: If there's a strong movement toward 64-bitness, you
may wish to increase the type-and-length to total 64 bits, so that the value
starts on a 64-bit boundary.  (Useful for loading an 8-byte nonce into a
register with one instruction.)

Dan