SNMP Trap Eventsource

As a precise example as to why this would be a useful feature:  vCenter alarms SNMP trap notifications.  At least in my experience these are sent from vCenter as v1 traps but all the juicy information is in the trap variable bindings.  Here's a trap sent from a CPU Usage Alarm:

1.3.6.1.4.1.6876.4.3.304.0: Green 
1.3.6.1.4.1.6876.4.3.305.0: Red 
1.3.6.1.4.1.6876.4.3.306.0: alarm.VmCPUUsageAlarm - Metric CPU Usage = 100% 
1.3.6.1.4.1.6876.4.3.307.0: SERVER-1 
1.3.6.1.4.1.6876.4.3.308.0: 3 
enterpriseOid: 1.3.6.1.4.1.6876.4.3 
generalCode: 6 
snmpVersion: v1 
specificCode: 203 
sysUpTime: 1778505188 
trapVariableBindingCount: 5

All the /really/ useful information is in the trap variables:

• 1.3.6.1.4.1.6876.4.3.304.0 (vmwVpxdOldStatus)
• 1.3.6.1.4.1.6876.4.3.305.0 (vmwVpxdNewStatus)
• 1.3.6.1.4.1.6876.4.3.306.0 (vmwVpxdObjValue - What alarm got tripped!)
• 1.3.6.1.4.1.6876.4.3.307.0 ( vmwVpxdTargetObj - What vCenter object tripped the alarm!)

Being able to filter on the contents of bound variables, and address them as tokens in alarm subject/message, as something like ##TRAPVAR01##, ##TRAPVAR02##, ##TRAPVAR03## would be a massive workflow improvement for us.