Form Randy Presuhn (I think he is the best skilled from the SNMP community w.r.t. UTF-8 and related topics) So the possible concern would/might be: It DOES however mean that some older SNMP entities will accept (and play back) values that would legitimately be rejected by newer ones. So the statement by Ned that we should return an error: Actually, I think it is preferable to treat them as protocol errors, due to the need for UTF-16 compatibility. Does that mean that values above 10ffff should be rejected? So if my older agents don't do that, is that a problem or a non-compliance? Bert -----Original Message----- From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com] Sent: vrijdag 10 januari 2003 19:42 To: 'Wijnen, Bert (Bert)' Subject: RE: RFC2279 to Standard Hi - I'm not sure why they're talking about UTF-16. It's bogus, and the surrogates it uses are not used in the UTF-8 transform. ISO 10646 and Unicode agreed to go from the full 31-bit range down to the 0..10ffff range. I think I raised the question (along with selecting one of the normalization forms) on the mailing list. As I recall, there was only one response, and the respondant didn't want to open that can of worms. RFC 3411 says: Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The agreements on Unicode/ISO 10646 just say that those code points in the 110000..7fffffff range will never be added. If the definition of "valid UTF-8 encoding" has been changed to encompass a smaller range, I believe the the statement "Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited" remains correct, and gives an implementation grounds to reject code points outside the 0..10ffff range. It DOES however mean that some older agents will accept (and play back) values that would legitimately be rejected by newer ones. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------