Re: [TLS] Clarification on vectors required

["neil.young" <[e-mail]>]

Hi Marsh,

thanks for the response. Meanwhile I got a similar answer from real TLS 
experts :)  Their statement was
"Hmm, no. The above rule states that the encoded size value (that is put 
to the first three bytes in your case) must be a multiple of the vector 
element's size (two in your case). E.g. if a type is defined as uint16 
data<0..2^24-1>, then the sizes encoded as 00 00 01, 00 00 FF and 00 FF 
FF are illegal (as neither of them is a multiple of two). 

If the type is defined as uint16<0..2^24-1>, then the 0x4711 value (one 
uint16 element) will be encoded as 00 00 02 47 11"

This is exactly what you said. The "size" _element_ has to be an even 
multiple of the element size. A  bit confusing, but logical finally.
Regards



Marsh Ray schrieb:
> On 4/1/2010 8:57 AM, neil.young wrote:
>   
>>> Given the following declaration:
>>>
>>> opaque             config_data<2^24-1>;
>>>       
>
>   
>> Is this understanding correct:
>>
>> 1) The declaration is slightly incorrect, because the "floor" element
>> is missing. I tend to treat it to be 0
>>     
>
> Looks like the lower bound is specified everywhere else.
>
>   
>> 2) The number of bytes expressing the length of the vector is 3,
>> large enough to count for 2**24-1 bytes
>>     
>
> Sounds right to me.
>
>   
>> 3) If e.g. the size of the vector's data is 2 bytes, do I really have
>> to add a pad byte in order to meet the "even multiple" demand?
>>     
>
> No. The length field does not need to be the same as the size of an
> element and it is not included in the "even multiple" requrirement.
>
>   
>> Is this correct? 00 00 02 47 11 0
>>
>> Or this? 00 00 02 47 11
>>     
>
> Either is correct, you defined it as 'opaque'. The opaque type is for
> "single byte entities containing uninterpreted data".
>
> It's only when vectors contain a defined type that this rule applies:
> "The length of an encoded vector must be an even multiple of the length
> of a single element (for example, a 17 byte vector of uint16 would be
> illegal)."
>
> Obviously, if the defined type is itself one byte in size then the even
> multiple requirement is always met.
>
> The example in the RFC:
>   
>> opaque Datum[3];      /* three uninterpreted bytes */
>> Datum Data[9];   /* 3 consecutive 3 byte vectors */
>>     
>
> The 9 must be a multiple of 3.
>
> The size of the length field does not need to be the same as the size of
> an element of the vector.
>
> There appears to be an unstated exception to the even multiple
> requirement for element types that may themselves be of variable length.
>
> This is just my interpretation, however. :-)
>
> - Marsh
>