> I assume that if the Line ID is going to be opaque we don't need to > define how to encode strings in it. Suresh's email wasn't clear on > that, if I understood it correctly.
The problem with this is if the field actually holds a string, you have to define a canonical representation for the string. It's just not sufficient to say it is a "string" or a "UTF-8 string", etc. You won't get interoperability with that. This is something *ALL* IETF protocols are starting to grapple with, if they allow protocol fields to hold strings, and one has to compare those strings for equality. > I still would like it to be an opaque field as that keeps it aligned > with the DHCP option. The DHCP format was specified many years ago... the world is more complex today... If we say specifically the opague field is not a "string", this issue probably goes away. But I think we need to ask the users of this option whether that is OK. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
