ResourceTiming API & byte-size

I'm wondering if there's any reason the resource's byte-size & compressed
byte-size were not added to the ResourceTiming API.

The use cases I see for adding this information to the API would be:
1. Enabling Web apps access to the full information required to create
complete waterfall charts or HAR files that are equivalent to the browser's
own Web Inspector/developer tools. Current demos creating a waterfall chart
[1] or HAR files [2] either ignore the file size altogether, or use the IE
only property of "fileSize" on image resources.
2. Detecting compression issues using RUM scripts (text resources that were
not GZIPed, automated image compression regressions).
3. Enabling Web applications to get a notion of the average download
bandwidth each resource had. Even though such a measurement may not be
accurate (because of slow-start, contention, packet losses, different hosts
per resource, etc), it may be useful information either for RUM or for
progressive enhancement purposes.

Thanks!
Yoav

[1]
http://calendar.perfplanet.com/2012/an-introduction-to-the-resource-timing-api/
[2]
http://blog.trasatti.it/2012/12/measuring-the-speed-of-resource-loading-with-javascript-and-html5.html