On Thu, 3 Jul 1997, Unicode Discussion wrote:
> Hi -
> The SNMPv3 working group of the IETF is hoping to make use of UTF-8
> for some human-readable information in the MIBs used to manage SNMPv3.
> The convention currently used for this kind of information is described
> on page 4 of RFC 1903. (For easy reference, I've appended the text
> to the end of this message.) We would like to define a new convention
> formulated in terms of UTF-8 for use in new MIBs.
> What we've not yet reached agreement on is the question of "non-printable
> stuff". Some believe that NVT ASCII's control characters are somehow
> less problematic than those of 10646, others find the problems equivalent.
> The questions that come to my mind are:
> 1) Is there any merit to the argument that the "non-printable
> stuff" in 10646 is any better or worse than the NVT ASVII
Because you are using UTF-8 and because many of the things mentionned
in your excerpt of RFC 1903 rely on properties of lower-level
protocols (e.g. CR NUL comes from telnet,...), I would clearly adwise
you to keep these as they are. This means that a lot of the software
doesn't have to be changed.
> 2) Can we use standard character properties to identify a
> "printable" subset that would not break for any language?
> (The folks that want these also want to have CRLF...)
> Background information:
> In the SNMP protocol notions of equality and ordering have no
> "locale" component. There is no notion of character equivalence.
> It is very much a "bits is bits" environment.
That's similar to the situation with URLs. Can you give some info
on where and how equality or sorting is used, and where it is crucial?
> The concerns of working group members appear to be arising from:
> 1) what does it mean to "support 10646"
> 2) how to display "wierd stuff"
> 3) how to input "wierd stuff"
What do you mean with "wierd stuff"? Some codepoints can lead to
rather complicated display or input code, but they are absolutely
necessary for the display of certain languages.
The question is how to come up with a rather flexible display requirement
clause without breaking the base functionality of the protocol. For HTML,
for example, it was rather easy to say that a browser is not required
to display a character, but that it should indicate the characters it is
not able to display in a suitable way ("missing character glyph",...).
Something equivalent may be possible for SNMP. Maybe one would have
to require that the Hex number of the character is given in a suitable
> 4) the old CR/LF problem
As I said, stay with it, don't change things unnecessarily.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:35 EDT