Re: issue-#49: Length indicator for Router Certificate sub-option

> James Kempf wrote:
>
> >All the length fields in CARD are 8 bits, which means restricts the size
of
> >messages to 254 bytes. This length is insufficient for certificates.
> >
> >An additional concern is that if the length field of the entire
> >Request/Reply mesage is the same as the sub-option length field, the
> >sub-option generator may want generate an option longer than would fit
into
> >the message, since this would be allowed by the field length. The
solution
> >for this in any case is for the sub-option generator code to respect the
> >overall limits on the message length, in addition to the sub-option
length.
> >
> >Proposal 1: Keep the length field size at 8 bits and make the units of
> >length be 8 octets, for a maximum 1634 bits  or 2048 bytes.
> >
> >Proposal 2: Change the length field size to 16 bits, for a total of 65535
> >bits or 8192 bytes.
> >
> >Suggested resolution: Proposal 2
> >
> >Reason: Proposal 1 could result in a maximum of up to 7 padding bytes of
> >null data in an option or sub-option which is an extra overhead that is
> >unnecessary and unwanted over the air.
> >
> >
> >
> Well, this is only my opinion, but if we transmit certs of size > 1kbyte
> over the air with
> a CARD Reply, who cares about 7 bytes padding... What bothers me with
> the 16-bit proposal is
> that potentially the length of this sub-option can be much larger than
> the length of the option it
> is encapsulated with, which is max 256 x 8bytes long. And even when
> having resolution of
> 1 byte with 16-bit length identifier, requirement for all sub-options is
> to take care about 32-bit
> boundary alignment.
> Hence, max overhead with proposal 1 is 4 bytes, right?
>
> What do others think?
>

So how about changing the size of the option to 16 bits as well?

BTW, if we do change the size to 16 bits, then I think the units should be
bytes and not bits. So the max size would be 65536 bytes.

            jak