PMP> Revised proposal on definition of OCTET STRING ...

PMP> Revised proposal on definition of OCTET STRING ...

Chris Wellens chrisw at iwl.com
Tue Jul 22 13:56:28 EDT 1997


Here is my second message (sorry these got out of order).


Here is an email exchange between Randy Presuhn and I where Randy
explains in some detail the use of UTF-8 in the sysappl MIB and the
plan for SNMPv3.  The reason I include this is to provide the technical
background on the reasons/advatages for this approach.


Tom Hastings' proposal, by clarifying the definitions of what is ASCII,
allows most implementations to remain unchanged, has minimal impact on
the MIB itself, but would allow other implementations to take advantage
of the things that Randy describes below.






>From rpresuhn at peer.com Thu Jul 10 17:49:12 1997
Date: Wed, 2 Jul 1997 12:13:48 -0700
From: Randy Presuhn <rpresuhn at peer.com>
To: chrisw at iwl.com
Cc: cheryl at empiretech.com
Subject: Re:  Use of utf8string in sysappl mib


Hi Chris - 


> Date: Wed, 2 Jul 1997 11:30:57 -0700 (PDT)
> From: Chris Wellens <chrisw at iwl.com>
> Reply-To: Chris Wellens <chrisw at iwl.com>
> To: cheryl at empiretech.com, rpresuhn at peer.com
> Subject: Use of utf8string in sysappl mib
> Message-Id: <Pine.SUN.3.93.970702111859.12472A-100000 at iwl.iwl.com>
> 
> Hi Cheryl and Randy,
> 
> We are moments away from finishing the Printer MIB, and have one
> last difficult issue -- localization.  


Cool.


> We were trying to cram this in as a last minute change, and were
> planning to modify about a dozen octet strings to make them TCs.  Then
> in talking to Dave Perkins and others, it was suggested that there
> should be a more general approach that would be useful for all SNMP
> MIBs and not unique or specific to the printer MIB.  I also
> noticed that RFC2130 on this subject gives examples of how
> current IETF protocols should be changed to support
> localization, however, there is no discussion of SNMP.  
> 
> I noticed that in the sysAppl mib you are using Utf8String and
> LongUtf8String.  
> 
> So, I was hoping that you had perhaps solved this problem for us
> and we could cut and paste from your work :-).  However, was your 
> plan to do this as phase 1?  and then address the other protocol 
> oriented issues later?  


I'd suggest cloning or referencing the TCs we did.


UTF-8 support is pretty painless at the agent side: bits is bits.
Likewise, on the manager side, a user interface can display and
handle input for whatever it happens to support.


This is actually not as bad as the problem of NVT ASCII with the high
bit set, since at least with UTF-8 there is no question of what a given
code point is supposed to represent.


As a practical matter, regardless of whether NVT ASCII or UTF-8 is in use,
a robust user interface needs to provide a way of entering and displaying
code points not directly supported by the input or display device.


Note that if the data being shovelled around is 7-bit ASCII, 
the UTF-8 representation is identical.  All that changes is the
processing of stuff with the high-order bit set on display/entry.


> At the moment the majority of the WG is feeling that this is a
> huge black hole and that we cannot possibly address it
> adequately at this late date.  I'm inclined to agree, but feel
> it is my ethical duty to seek out all possible solutions.  If
> you've got one, we should try and use it.  Can you help?
...


It is possible, but not necessary, to turn it into a black hole.
(See the acap mailing list for an example.)  My own perspectives:


	1) support for almost every language in use.  This is a HUGE win.
	2) little or no impact on the agent side (the only
	   issue is the implementation-specific approach to mapping into
	   the target system's native character set; the easiest thing
	   to do is to just leave it in UTF-8 all the time.  (IBM faced
	   similar issues in agentx regarding NVT/EBCDIC translation,
	   as did we in our MVS port; in both cases the final decision
	   was that trying to translate stuff causes more problems than
	   its worth.)
	3) little impact on the manager side.  Robust manager code
	   already needs to cope with code points not directly supported
	   by input or display hardware.  Compared to the effort required
	   to handle other internationalization/localization issues
	   (if a product is internationalized/localized at all), this
	   gets lost in the noise.  If the product is stridently English
	   only, all it needs to do is not explode when it gets one of
	   these interesting code points.  Since this can allready occur
	   with NVT ASCII, this is not a new problem.
	4) The acap issues of language/locale tagging, while interesting,
	   appear to me to be serious overkill for management applications.
	   There is even some argument about whether the requirement for
	   language tagging in RFC 2130 is overstated; the current
	   discussions would indicate that what is really intended is locale
	   rather than language information.  Until this is sorted out,
	   I think it's best for us to not dive into that particular
	   debate.  For the needs of management systems, the locale of
	   the management system should control display and data entry,
	   rather than information included in attribute values.
	5) This is the direction the world is going.


We're in the process of defining a TC to go along with the SNMPv3 work
to use UTF-8 for all the human-readable information in the MIBs
associated with the management of SNMPv3.  Current status:
	1) It will be UTF-8
	2) Whether it can be meaningfully constrained to "printable" 
	   is under investigation.  (It looks to me like such a constraint
	   is more trouble than its worth, but I'm still looking into it.)


 ---------------------------------------------------------------------
 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 at 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."
 ---------------------------------------------------------------------
>From rpresuhn at peer.com Thu Jul 10 17:49:24 1997
Date: Wed, 2 Jul 1997 19:18:41 -0700
From: Randy Presuhn <rpresuhn at peer.com>
To: chrisw at iwl.com
Cc: cheryl at empiretech.com
Subject: Re:  Use of utf8string in sysappl mib


Hi Chris - 


> Date: Wed, 2 Jul 1997 14:43:52 -0700 (PDT)
> From: Chris Wellens <chrisw at iwl.com>
> To: Randy Presuhn <rpresuhn at peer.com>
> Cc: cheryl at empiretech.com
> Subject: Re:  Use of utf8string in sysappl mib
> Message-Id: <Pine.SUN.3.93.970702144317.13280D-100000 at iwl.iwl.com>
> 


The important thing that folks need to understand about UTF-8 support
is that a product does NOT have to UNDERSTAND every single one of the
40,000+ code points defined in IS 10646; a product does NOT need to be
able to display Chinese to support UTF-8.  Rather, it just needs to use
the correct code points to represent information from whatever languages
it DOES support.  Any other code points can be treated as opaque stuff
to shovel around, just like any other mystery bytes one might receive
in a DisplayString.  (Concrete example: how should 0xFF be interpreted?
In NVT, the answer is unclear.  With 10646, the answer is simple.)
For the gory details, see
http://www.unicode.org/Unicode.charts/normal/U+0080.html


Sorry if I sound like I'm lecturing.  I care about this a lot.  
I wish you the best of luck in getting this adopted!


 ---------------------------------------------------------------------
 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 at 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."
 ---------------------------------------------------------------------




-----------------------------------------------------------------------------
--==--==--==-  Chris Wellens             President & CEO
==--==--==--=  Email: chrisw at iwl.com     Web: http://www.iwl.com/
--==--==--==-  InterWorking Labs, Inc.   244 Santa Cruz Ave, Aptos, CA 95003
==--==--==--=  Tel:  +1 408 685 3190     Fax:  +1 408 662 9065
-----------------------------------------------------------------------------



More information about the Pmp mailing list