Part 4 currently state (Table 128, MonitoringParameters):
"For event monitored items the value is ignored and the server shall set the supported maximum queue size as revisedQueueSize."

This makes sense when the item is reporting. However, when the item is only sampling and later turned to reporting it might not be a good strategy. Clients might only want to get the latest events (e.g. 100) and not the full queue size for monitored items in the server. In this case the client shall be able to set a resonable queue size. One example is hot redundancy where clients might enable reporting in failover and do not want to get a potential very long stream of events they already had received.

Recomended change discussed in the F2F meeting in Florida, January 2012 is to recomend 0 but allow other values for the queue size as well.