Opaque types

Leo Cacciari <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
Hi,
  I'm writing a SNMP (sub)agent which would allow access to some
application data. Data types handled by the application, and that should
somehow be exposed to the SNMP world by the agent, includes the
'standard' SNMP types (e.g. 32 bits integers or [display]strings), some
sub-types of those (e.g. 16 bits integers) and other types that are more
difficult to map directly on SNMP types, although there is (obviously)
no problem in mapping them to ASN.1 (that's the reason to have ASN.1,
after all..).

My first thought was to use OPAQUE type, adding necessary information
using the DESCRIPTION clause. This idea seems to be supported by the RFC
stating: "The Opaque type supports the capability to pass arbitrary
ASN.1 syntax". However, the RFC also states that "The Opaque type is
provided solely for backward-compatibility, and shall not be used for
newly-defined object types.".

My question to the collective wisdom is thus two fold:

First, am I right in using the OPAQUE type? Or should I use another
approach? Second, assuming the answer to the first question is "yes",
how should I approach the problem of encoding/transmit/recover data
using the OPAQUE data types?

Thanks in advance to anyone providing help...

Leo

-- 
Leo Cacciari
Aliae nationes servitutem pati possunt populi romani est propria libertas


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.