Wrong data layout for DHCPv6 option bootfile-param?

[Celelibi]

2015-08-27 2:05 UTC+02:00, Shawn Routhier <sar at isc.org>:
>
>> On Aug 26, 2015, at 4:35 PM, Celelibi <celelibi at gmail.com> wrote:
>>
>> Hello,
>>
>> I've seen that the DHCPv6 option 60 has been implemented. However, I
>> think the data layout sent on the network is wrong with respect to the
>> RFC 5970.
>>
>> The current implementation send this option as a single string. I.e. a
>> 16 bits integer representing the size of the string and the sequence
>> of bytes of the string.
>>
>> The RFC 5970 say that the data layout of this option start with the
>> total byte size on a 16 bits integer, followed by a sequence of
>> strings (length + bytes).
>>
>> Have I understood something wrong or is this really a bug from the dhcpd?
>
> Neither.  This is a limitation of the description and parsing code used
> to manage the options.  With the current description it isn’t possible
> to represent the multiple variable length fields that the option describes.
> The closest we currently have is X - ascii or binary - in which you would
> need to pre-format the parameters into a single string.

That's what I did. But I don't think it's the most readable or
maintainable thing ever.

option dhcp6.bootfile-param = concat(encode-int(3, 16), "ABC");

If it's not a bug, I guess there is no plan in adding the support for
a sequence of strings data type in the near future. Am I right?