I am not sure this answers your question. Please be more precise if
I missed the point,
.
.
.
I'll interrupt this conversation, because I've been
over a lot of the same ground myself, and perhaps I
can communicate with both sides.
We need to emphasize a couple of points to Thorsten
Geelhaar: Scotty handles OCTET STRINGs consistently
and correctly; some other SNMP products/libraries/...
you might encounter *are* "tricky" in that they can
lose and/or mangle data; and you need to understand
the role MIBs play in Scotty's operation.
Let's work through an example, or a fragment of an
example. Suppose you're some sort of Scotty-based
application, and you've just received a varBind for
a sysDescr.0 value. It arrives as UDP data which
can be anything, including potentially ...0d:0a...
(the "0d" and "0a" are two consecutive bytes, or
more precisely octets, making up the value). From
the outside, Scotty appears first to transform
those hex bytes into a fully displayable transcrip-
tion, "...0d:0a..." (that content in the middle
occupies five characters: the character '0', the
character 'd', the ...). If, however, Scotty
knows of a MIB which describes sysDescr as a
DisplayString, then it will follow the RFC and
simply report the OCTET STRING as a string, two
of whose characters are conventionally CR and LF
(with the values 0x0D and 0x0A).
This is completely consistent. Problems can only
arrive if you can't display NVT ASCII (possible,
but then it's a bigger issue than just OCTET STRINGs),
or if you somehow have a MIB that convinces Scotty
a particular OID is a DisplayString (has DisplayString
formatting) when it's not. That's an error in the
MIB, of course, and also outside Scotty's control.
Cameron Laird
Network Engineered Solutions http://starbase.neosoft.com/~bodi/nesi.html
claird@calladan.com +1 713 763 8366
claird@NeoSoft.com +1 281 996 8546 FAX
Houston WWW Business Guide: http://starbase.neosoft.com/~bodi/HouGuide.html
-- !! 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.