Re: Octetstrings

Cameron Laird (claird@Starbase.NeoSoft.COM)
Sun, 2 Feb 1997 14:12:32 -0600 (CST)

From owner-tkined@ibr.cs.tu-bs.de Thu Jan 30 14:52:09 1997
Date: Thu, 30 Jan 1997 19:21:16 +0100
From: Juergen Schoenwaelder <schoenw@cs.utwente.nl>
.
.
.
An ASN.1 OCTET STRING can contain all kind of bytes, even 0x00. Some
"types" derived from the ASN.1 OCTET STRING place some restrictions on
the allowed character sets. The most prominent example is the
DisplayString textual convention (RFC 1903), which limits the allowed
bytes to the NVT ASCII character set. Note that your example fits into
the NVT ASCII set as well. So the answer is: Yes, you can have
unprintable characters in an OCTET STRING. The agent has to deal with
it. The scotty agent will store a generic OCTET STRING in the
primitive OCTET STRING notation, 0d:0a.

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.