Re: Confusing illustration for 3.2.11

You are right that the illustration is not correct with respect to
representing the ELEMENT_DATA field: It is not padded and does not have
to be aligned to 4 octets. Only the overall OPTIONS element is 4 octet
aligned.

Would this diagram be better:

0                   1                   2                   3=20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|            ELEMENT_T          |         ELEMENT_LENGTH        |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|                         ELEMENT_DATA    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...

Henrik

>In the draft there's a illustration in section 3.2.11 showing=20
>the layout of ELEMENT_T, ELEMENT_LENGTH and ELEMENT_DATA.
>
>The ELEMENT_DATA block has "/" left and right borders,=20
>indicating a padding on a 4-byte boundry.
>
>The text that accompanies the illustration says:
>
>"....
>The length of each element does not have to be a multiple of 4
>     octets and there is no padding between elements. However, the size
>     of the OPTIONS field MUST be a multiple of 4 octets. If the length
>     of all the elements is not a multiple of 4 octets, the generator
>     MUST pad the OPTIONS field value with all zero octets. Padding is
>     not included in the OPTIONS_LENGTH field (see section 3.2.7). ..."
>
>The text *before* the illustration indicates:
>
>"The OPTIONS field contains 0 or more option elements where each
>     element follows the layout in Figure 4 (see section 2.4 for a
>     description of option elements): "
>
>If the illustration is an example of a single element (as I=20
>read this), then the "'/' walls" indicating padding should not=20
>be there. They should only be in the illustration for 3.2.