One thing that surprises me about the RSS 2.0 specification is that, while there is an optional "image" element for the channel, complete with subelements for URL, title, link, width, height, and description, there is no image element for items. Instead, items have an "enclosure" subelement, with attributes for URL, length and mime type. While enclosures can be used to specify an image (and other media like sounds, videos, etc.), the lack of some of the subelements that exist with a channel image make it much less useful for specifying images.

For example, say you're rendering an RSS feed on a website. If it specifies a channel image, including it's dimensions, the RSS parser can scale the image automatically to fit the requirements of the website. With an item enclosure, since the dimensions are unknown, the best the parser can do is fix either the height or the width of the image (or both, but that would probably lead to distorting the image because of an incorrect aspect ratio). Also, with the channel image, the parser can constrain the display of the image to maximum dimensions, but not scale it if it is large enough already. This is not possible with enclosures. (Okay, technically, if the parser itself downloads the image and checks its dimensions, it could do it, but that would waste bandwidth and require a lot of work that could be easily avoided.)

So, my question is, why not use the same format for image elements within items as are used in the channel? I can't think of a single reason not to do this. An RSS reader or parser could share the code for handling the images between the channel and item sections, so it would not place any technical burden on tool creators, and it would sure be useful.

Note that I am not saying the enclosures are unneeded--for things other than images, enclosure is still needed.