Here's what I want to say about that: You cannot sort exploits into any distinct categories without oodles of work and a lot of hand-waving that makes it useless for regulation. I'm not saying this to pick on this particular paper or its categories, which derive from one of Mikko's more morose ruminations on the subject. It's a common problem and a real issue with designing intelligent policy in this space.

Let's talk briefly about this one vulnerability to explain how hard this can be. The Spooler exploit was two phased:

You could use a bug in the remote procedure call (RPC) endpoint to write arbitrary files to arbitrary places on the disk as "Admin". This is useful, but is not remote code execution (you cannot overwrite files).

Imagine trying to ban 0day exploits that "allow for remote code execution". Would the Spooler vulnerability fall into that regulation? Perhaps only when combined with the knowledge of MOF files or the ATSVC technique? What about when you realize that the vulnerability was already in a Russian magazine? What about how the code it allows you to execute is VBScript, and not native code? And how it only effects Windows systems that share printers or have a specific configuration?

There's a thousand different categorizations you could apply to exploits, is what I'm saying, and none of them are universally available or even technically correct in a majority of cases. Right now the policy world tries to ignore this with legalistic jargon, but the physics of the problem are not going to change to make it any easier, unfortunately.