When in doubt, you should check the RFC (RFC 2453, RIP Version 2, Section 3.10.1, Triggered Updates):
3.10.1 Triggered Updates
Triggered updates require special handling for two reasons. First,
experience shows that triggered updates can cause excessive load on
networks with limited capacity or networks with many routers on them.
Therefore, the protocol requires that implementors include provisions
to limit the frequency of triggered updates. After a triggered update
is sent, a timer should be set for a random interval between 1 and 5
seconds. If other changes that would trigger updates occur before the
timer expires, a single update is triggered when the timer expires.
The timer is then reset to another random value between 1 and 5
seconds. A triggered update should be suppressed if a regular update
is due by the time the triggered update would be sent.
Second, triggered updates do not need to include the entire routing table. In principle, only those routes which have changed need to
be included. Therefore, messages generated as part of a triggered
update must include at least those routes that have their route change
flag set. They may include additional routes, at the discretion of
the implementor; however, sending complete routing updates is strongly
discouraged. When a triggered update is processed, messages should be
generated for every directly-connected network. Split Horizon
processing is done when generating triggered updates as well as normal
updates (see section 3.9). If, after Split Horizon processing for a
given network, a changed route will appear unchanged on that network
(e.g., it appears with an infinite metric), the route need not be
sent. If no routes need be sent on that network, the update may be
omitted. Once all of the triggered updates have been generated, the
route change flags should be cleared.