It depends if "scalar" or a "table row"-related varbinds are being referred to in the trap.
http://www.net-snmp.org/wiki/index.php/TUT:snmptrap states :
Note that this command also includes an (OID,type,value) triple for
the varbinds listed in the VARIABLES clause (in the same way as with
the snmpset command).
Table row example.
snmptrap -v 2c -c public host:162 .1.3.6.1.6.3.1.1.5.3 .1.3.6.1.6.3.1.1.5.3 \
ifIndex i 2 ifAdminStatus i 1 ifOperStatus i 1
For reference :
snmptranslate -m +ALL -Pu .1.3.6.1.6.3.1.1.5.3
IF-MIB::linkDown
No .0 in the variable bindings since id is taken care of by the ifIndex which pinpoints the row.
Scalar row example.
http://www.net-snmp.org/wiki/index.php/TUT:snmptrap shows example
snmptrap -v 1 -c public host UCD-TRAP-TEST-MIB::demotraps "" 6 17 "" \
SNMPv2-MIB::sysLocation.0 s "Just here"
'SNMPv2-MIB::sysLocation.0' is a scalar.
Unlike IF-MIB::linkDown example above, which was related to a table row id-ed by the ifIndex, here the .0s at the end pinpoints the scalar (like when you SET it)
Netsnmp example from original question
mibs/NET-SNMP-EXAMPLES-MIB.txt states
netSnmpExampleHeartbeatRate OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"A simple integer object, to act as a payload for the
netSnmpExampleHeartbeatNotification. The value has
no real meaning, but is nominally the interval (in
seconds) between successive heartbeat notifications."
::= { netSnmpExampleNotificationObjects 1 }
i.e. it is not a real, identifiable, accessible scalar so I recommend no .0.
