Hi Suresh, > Will do. Would a simple statement e.g. that it is a null terminated text > string be sufficient or did you want more details?
There's no need for it to be NUL-terminated. In fact that's asking for trouble because what do you do if the NUL and the field length don't match? What application programmers need to know is: - that the field can be printed - what character set to use for the printing and input - what to do if a non-compliant string is encountered (eg, non-printable chatacters, or a failed UTF-8 encoding). A reasonable action would be to never attempt to print the field, fail any comparisons, and generate a small number of log messages containing enough information for debugging but without allowing an attack vector on the logging device (ie, don't print the errorred string, hex dump it or escape non-printing characters). - how to compare the field. Byte-by-byte makes sense; that is, the locale is irrelevant. As you can see, there's a fair few issues avoided by that convenient word "opaque". It's a fine word to describe bytes on the wire: it says that middleboxes shouldn't tamper with the field. But it's a poor word for use at endpoints, as it amounts to underspecification of the field and thus divergent practices or reverse engineering. For example, one compliant router could use a twos-complement counter, another could use ASCII, another could use a random nonce. Without further specification of the "opaque" field all that a compliant provisioning system can do is require the field to be input as hex. Ironically, only a non-compliant provisioning system could accept input as a string, which is the intended use of the field. The contents of the DHCP Relay Agent Information Option fields in RFC3046 are said to be opaque but then it is immediately suggested that the contents are textual. For example, "The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only". To my mind RFC3046 isn't a good specification because all it does is raise ambiguity in the implementer's mind and send them off to look at other implementations for guidance. This is much more writing than the issue is worth. My apologies for taking up your time. Best wishes, Glen -- Glen Turner <http://www.gdt.id.au/~gdt/> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
