What seems more interesting to me is the following: The MUA
finds an http: URI, and invokes the browser. The browser
resolves the http: URI, and fetches a document with media
type message/rfc882. The browser then invokes the MUA to
handle that media type. That way, the browser actually
does some work, rather than just playing ping-pong.
while this kind of "display this URI" functionality is typically
supported by web browsers, I'm not aware of any email MUAs that support
it.
it's pretty easy to implement enough of http to do a GET (including
handling of redirects), so I'm not worried about the burden on the MUA
of doing that. what does concern me is that the MUA doesn't reliably
know whether it can handle the resource until it actually does the GET.
it could then pass the downloaded resource to the browser, but that
tends to mess up things like relative URIs. so the decision of whether
to handle the resource itself or to pass it off to the browser has to
happen after the GET. (granted, it could do a HEAD, but that's still
awkward).