>>>>> David Harrington writes:
David> This is a very limited sample, but it appears that changing
David> from DisplayString to SnmpAdminString is not problem in the
David> tested cases.
I think it depends on what you consider to be a problem.
David> I suggest that we try to get a larger sample, especially from
David> the market leaders, and for the major PD utilities/toolkits.
David> I hereby make the formal request to vendors/implementors to
David> test their implementations and provide that information to
David> dbh@cabletron.com or to mundy@tis.com so we can understand the
David> potential impact of the proposed change.
The currently "fielded" version of the Tnm extension for Tcl (better
known as scotty) takes the OCTET STRING input without further checks
on the repertoire. A UTF-8 string will show up as garbage (or some
funny characters - depending on your system). Since the Tnm extension
is just a high-level scripting interface, I can only guess what
scripts above the Tcl API layer will do. Scripts that receive garbage
may or may not go crazy.
Based on the discussion here on the list (and my recent study of the
source code), here is what a future version will do. (Warning: This is
only rudimentary available on my notebook and it will take quite some
time until a new stable version will have replaced the fielded
releases.)
The way I deal with this issue is probably very different from other
interpretations. I generally dislike to hard-code special semantics
for TCs or variables in the engine. I want code to be as generic as
possible. I therefore prefer to get all the relevant information from
the MIB definitions and to have generic code to do the right thing. In
fact, the Tnm code relies on the DISPLAY-HINT to do all the formatting.
And here is how the current implementation will change:
(a) When applying the 'a' specifier, I will check for valid ASCII as
defined in RFC 2579 section 3.1 clause (3). Data that is not valid
ASCII will not be formatted and returned as "binary" OCTET STRING
data. (This check is currently missing.)
(b) There will be support for the 't' specifier as defined in RFC 2579
section 3.1 clause (3). Data which belongs to a type which uses
the 't' specifier will be interpreted as UTF8 and converted into
the relevant unicode representation. If the data is not valid
UTF8, it will be returned as "binary" OCTET STRING data.
(The 't' specifier is currently not recognized.)
(c) The type information in the Tcl representation of the varbind list
will be either DisplayString (in case a), SnmpAdminString (in case
b) or OCTET STRING (if the application of the DISPLAY-HINT in case
a or case b failed). (This is a major change in the Tnm API since
previous versions always returned the underlying SNMP base
type. But this change makes sense as it gives more information to
the scripts and since it decouples the on-the-wire representation
from the type seens by management applications, which is important
when moving to SMIng and libsmi, which is another item I am
working on.)
The fun part of this solution is that SnmpAdminString in RFC still
uses the "255a" DISPLAY-HINT (since it was published before RFC 2579)
and hence using SnmpAdminString for sysLocation et. al. won't formally
work until RFC 2571 gets republished. :-)
/js
-- Juergen Schoenwaelder Technical University Braunschweig <schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.
This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 15:27:32 MET