Hi -
> Date: Fri, 4 Jul 1997 12:16:02 +0200 (MET DST)
> From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
> To: Randy Presuhn <rpresuhn@peer.com>
> Cc: Multiple Recipients of <unicode@unicode.org>
> Subject: Re: UTF-8 in SNMPv3
> Message-Id: <Pine.SUN.3.96.970704114736.253k-100000@enoshima>
...
> > 1) Is there any merit to the argument that the "non-printable
> > stuff" in 10646 is any better or worse than the NVT ASVII
> > definition?
>
> 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.
Seems reasonable.
> > 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?
I like the analogy. The matching for equality is important when an
attribute is used as an index into a table. Sorting is important in the
same situation, in the context of the "GET-NEXT" operator. The rules
for representing an OCTET STRING (the only data type SNMP has that can
hold this kind of information) as an INDEX and GET-NEXT processing admit
no possibility of alternative collation sequences.
> > 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.
Understood. A few of us in the working group have had some contact
with internationalization issues; many have not. The concerns seem
to be motivated by the fear that supporting 10646 would require them
to junk command line and character-mode interfaces. (Such a requirement
would probably kill whatever support UTF-8 has within the working group.)
> 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
> form.
What standards for the display and entry of "undisplayable stuff" would
be good hints for developers?
> > 4) the old CR/LF problem
>
> As I said, stay with it, don't change things unnecessarily.
Folks like to hear advice like this. :-)
> Regards, Martin.
>
Thanks!
---------------------------------------------------------------------
Randy Presuhn BMC Software, Inc. (Silicon Valley Division)
Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com
Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130
Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA
---------------------------------------------------------------------
In accordance with the BMC Communications Systems Use and Security
Policy memo dated December 10, 1996, page 2, item (g) (the first of
two), I explicitly state that although my affiliation with BMC may be
apparent, implied, or provided, my opinions are not necessarily those
of BMC Software and that all external representations on behalf of
BMC must first be cleared with a member of "the top management team."
---------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:35 EDT