[tkined] Re: publicly available testing of UTF'ed sysLocation

From: Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Date: Thu Jan 20 2000 - 11:47:36 MET

>>>>> 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

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. :-)


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