Thomas, On Dec 2, 2011, at 8:53 AM, Thomas Narten wrote:
>> 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. Still seems to me that if it's opaque, then it's opaque and we don't need to specify rules for it's contents. If it's not opaque, then we should specify rules. > >> 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... Is anyone asking to change that? If it's working, then it's not..... > 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. Hopefully they will respond to this thread. Thanks, Bob > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
